VCS is a generic term. It really depends on which system you use and how it is configured. I mainly work with SVN and in our case each revision is a copy of the file system after each commit not a delta. In addition we create a tag at the end of each sprint, which is also a copy of the file system.
Far from the same thing.
Dave, VCS systems have come a long way since the olden days ;). And we all have horror stories. Heck, I once had an optimizing compiler produce incorrect code, but I would be stupid to not use optimization today.
Then Tim, could you explain how a modern VCS system does work (saving full code each version makes no sense), especially if you have multiple developers altering things at the same time
If you pick one, Dave, I bet someone can get in to a little more detail that you’d like to know about.
“pick one”? I thought the basic operating premise was pretty much the same… .is was just the “sugar” that made them “different”
but if they all work differently, then no worries… I will continue to refrain from the use of any such package until forced to use it by an employer…
I meant, they’re more robust and less likely to fail. But to each his own.
Wow… I ask a simple educational question…
Fail or not fail… that was not the question… the question was … “Was my description of the process anywhere close to accurate?”
If so, even if the process worked as designed, I still fail to see how it can be accurate (and fast) over multiple alterations, branches and developers all touching things at the same time.
Yes, it does work essentially as you described. And yes, it does work quite well with multiple developers and branches and multiple changes all happening at the same time.
It should be noted that VCS is not backup. If your VCS isn’t being backed up, it’s close to useless. Your objection to VCS has nothing to do with VCS and everything to do with lack of backup.
Edit: corrected my overly-helpful autocorrecting phone.
Oliver, even if you cannot afford a license that would enable saving in text format, I still recommend you adopt some strategy to save your binary projects in a way that enables you to go back in time if the current project manifests an unrecoverable bug, or if for some reason you have changed some parts of the program and they don’t perform as they did before.
In essence, saving different versions of the project as you go along is a form of version control, but you won’t be able to see the changes in the project itself, so you may want to document these changes more extensively in the version comments.
I personally use git but you got to pay to have private repositories. I see this is recommended in a thread for Windows users : http://tortoisehg.bitbucket.org/
Using a specialized software will simplify the management.
There are probably other solutions available.
This is what I do. When I’m about to embark on a major change I’ll save as, incrementing a version tag and adding the intent of this next stage, ie “AudioRecorder 3c (new storage)”. I like number-letter for version, 1a, 1b, 1c, 2a, 2b where the number changes for really big steps.
As the project gets complex, robust and stable, where I’m more cautious about changes, adding a version Note to the App (or a Module just for Notes) really helps. Every change I’ll log where that change is and maybe a bit about why, the date, and which version, like this
[code]14-9-29 =========================
-moved normalizeFull/Scale from g.draw to g.lightModel
14-9-28 ========================= 1k0
-added g.xform.scaleX/Y/Z/XY
-building more OrthoCamera
14-9-25 =========================
-fixed EZFont.drawString YTop parameter from integer to single
14-9-24 ======================== 1j3
-added g.buffers.clear (overload)
-added a bunch to g.buffers
-added g.draw.shapes.roundRect*
-added more g.draw.shapes.circle*[/code]
This can be cumbersome when making a lot of little changes but really nice to see when coming back to the project after several months.
I made a similar app but my understanding is releasing such is forbidden. Arbed has some special exemption.
I went as far as getting permission, but didn’t take it any farther.
@Will Shank: this sounds very cumbersome. Way too much work.
Sometimes it’s a little tedious but not much. Guess it depends on your habits. My habit is after finishing some code I go through and tidy it up a bit, remove the testing/experimental stuff, and write some quick comments about what’s important to notice in the code. At that point it’s complete and I can move on to the next thing. Except when I’m really tracking a project I’ll also just switch to the version note and write a quick line about what’s done.
I’m not suggesting this for a multi-developer project. As a solo coder targeting a single platform (and not the wealth to justify $200 to save as Text Projects) this methodology is working for me.
Don’t be religious about it though. If a lot of little things changed in several places a single line could work. It’s really just an extension of getting in the habit of commenting code. Took 10 years for that. If I could afford Text Format I’d definitely use it, but short of that this solves some project tracking problems for me.
[quote=290619:@Will Shank] @Tim Hare I wrote an app that I use internally to compare binary projects and show the diffs. I have thought on occasion about making it available for sale
I made a similar app but my understanding is releasing such is forbidden. Arbed has some special exemption.[/quote]
it’s not forbidden to make one even using xojo. read the EULA in the about box
you are allowed to make and sell IDE, you only have to show somewhere “made with xojo”.
it was forbidden in the old realbasic-studio times.
Guess:
Maybe some people with license that enable them to save their project(s) as TEXT just need a (more or less) solid tutorial to get started with a GIT software ?
How do I do Backup / Comments ?
As said earlier, I do regular backup (but this is not enough *).
I set a Backup Project in each new Project folder and store a copy there (and I append that day as SQL Date to differenciate the projects).
When all is OK in my mind, I add one or more Note(s) into App, Window, Module, whatever to explain what changes I am doind / have done.
In code, I try to add comments
everywhere (to be able to understand what I’ve done). The main changes in code (even in an If
/
End If block) I put the date with time into brackets, followed by an explanation.
Refactoring: I create a brand new note and place the current code (before change) with date and eventually explanation, then I start to refactor the code.
Nota: Because I have tons of strange things (like a method that worked yesterday, but do not do that today, all of the above is starting to be boring. I even saw a stand alone feature that stopped to work
What I have to do is to use an rtf file to keep track of what I want to recall (keep track), in the project folder and drop it in the project so I will have it handly. But we all know what happens to I have to do
I have purchased Desktop Full. It wouldn’t hurt for me to chip in some support for the Xojo developers. Thanks for all the help.
I would not that version control systems can help you keep a backup very easily using the push functionality. BitBucket allows one private project for free so all your backups can go on there as long as it’s only one project. Personally I have no issues developing one project as a sole developer and hosting it on BitBucket.
SourceTree, Git and BitBucket work great for me and I don’t want to move away from this so I did go and purchase the more expensive option for Xojo. It’s really neat that I get some of these products and services for free.
Thanks
You can pick up a free private repository from Assmebla and get going for free privately with source control 