Question What version control system do you use in add-on development?

[Face]

This is something that I wondered about for some time now. I know that certain big projects use CVS, SVN and the like. I'm using Mercurial myself, as many will know.

But what about the casual add-on developer? What do you use to keep your code/mesh/texture versions under control?

Just curious...

 

[MeDiCS]

For small, one-shot projects, no version control at all (and later moved to a Git repository for small projects). Git for everything else.

I have experimented with SVN, Bzr and Mercurial, as they are used by some other projects I tinker with, but Git is by far the fastest and most transparent (the combination of Git procelain + shell script has saved me a lot of headache while recovering from 'accidents').

 

[Artlav]

Git, the only one i could actually get to be useful.
Occasionally make ZIP snapshots of non-recoverable parts, to be stored into backups.

Advantage of ZIP is that you can unpack it on any machine and continue working, then pack back and merge at home. Hard to do with GIT.

Advantages of GIT is high fidelity change log with mandatory comments on what was changed. Hard to do with ZIPs.

 

[RisingFury]

The amazing mental abilities of escapetomsfate, who's honorably tolerated my distrust of version control systems...

 

[kamaz]

I use Subversion for my add-ons, primarily because that's what I use for everything else (including documents). I have been a dedicated user of SVN ever since it saved my M.Sc. work from perishing 1 month before defense :facepalm:

I have looked into mercurial etc., but decided that because of my work style there would be no benefit over SVN.

 

[kuddel]

Hi use Subversion for almost everything (docs, code, whatever)
The main reasonings are:

• Its simple to use
• It does merging and branching very well
• It integrates very nicely into the (Win7) OS. (I love TortoiseSVN!)
• Its version numbering is much more 'natural' (ascending integers) than Git hashes. I like it when I can see immediately that rev. 123 is newer that rev. 120
• No need for any server process (just place your Repositories anywhere on your harddrive - I prefer: C:\Program Data\SVN\...). OK that argument goes for git/mercurial as well I think, so no winner/looser here

/Kuddel

 

[Zatnikitelman]

I, um...*cough* uh don't really do version control. I need to, and I'm considering GIT, but other things keep getting in the way of me sitting down and working with it.

 

[Enjo]

Subversion because I'm too lazy to learn Git/Mercurial. SVN failed me many times in branching and merging, but perhaps I'm also too lazy to learn it throroughly. I really enjoy having my SVN repo on a FAT32 partition, so that I can use it from Windows and Linux.

I also treasure Eclipse's automated file versioning.

 

[MeDiCS]

I really enjoy having my SVN repo on a FAT32 partition, so that I can use it from Windows and Linux.

NTFS works fine on both OSes.

 

[SiameseCat]

Mercurial. Mainly because of Mercurial Queues, which lets you edit unfinished changes before committing them.

 

[martins]

I'm using SVN for orbiter development, GIT for most work-related stuff.

 

[BruceJohnJennerLawso]

Noob moment, but what do you need version control for? Do some projects actually take up so much room that they must be archived, or does it make it faster?

 

[Artlav]

Noob moment, but what do you need version control for?

Now it works, now it don't.
What happened?

With a change-by-change log of changes (which is the main use of VCS), it's easy to find out.

With a single, constantly changed project that you last backed up a week ago - it's anyone's guess, and no way to roll back.

 

[BruceJohnJennerLawso]

Now it works, now it don't.
What happened?

With a change-by-change log of changes (which is the main use of VCS), it's easy to find out.

With a single, constantly changed project that you last backed up a week ago - it's anyone's guess, and no way to roll back.

So, a program that just archives code and other project files for you in case of :facepalm:.

So hyperventilation isnt the only solution to ones project exploding after all!!! Still, I think I can wait before I start using one, my project shouldnt need too many changes at all before being release ready. Just waitin on the big Tuesday of Dansteph...

 

[NukeET]

Now it works, now it don't.
What happened?

With a change-by-change log of changes (which is the main use of VCS), it's easy to find out.

With a single, constantly changed project that you last backed up a week ago - it's anyone's guess, and no way to roll back.

I used zip files and folders for version control on Niven ver.3. Damn near lost my mind. I actually would have if I hadn't had some way of going backwards.

Ironically, I voted for, "What is version control?" in the poll.

Thanks for starting this thread, Face.

 

[dbeachy1]

I had been using sequential zip backups until this weekend -- now I have everything in the XR codebase under Perforce (which is not in the list). I had been meaning to do that for a while now and this thread reminded me.

 

[Face]

I had been using sequential zip backups until this weekend -- now I have everything in the XR codebase under Perforce (which is not in the list). I had been meaning to do that for a while now and this thread reminded me.

Perforce is another conventional (centralized) VCS. Option 4 would fit here.

Nice to hear my curiosity brought you back on track, so to say.

 

[Ripley]

Among these, which is the one you'd suggest to a noob who never used such a system and doesn't want to be intimidated?

 

[agentgonzo]

I used to use subversion for all my stuff (work and addon dev) but I have since moved to git for work and don't have the time anymore to do addon dev stuff. If I did, I would move to git in an instant though. The learning curve for git is very much steeper than subversion. I have heard good things about mercurial too though.

Hi use Subversion for almost everything (docs, code, whatever)
The main reasonings are:

• Its simple to use
• It does merging and branching very well
• It integrates very nicely into the (Win7) OS. (I love TortoiseSVN!)
• Its version numbering is much more 'natural' (ascending integers) than Git hashes. I like it when I can see immediately that rev. 123 is newer that rev. 120
• No need for any server process (just place your Repositories anywhere on your harddrive - I prefer: C:\Program Data\SVN\...). OK that argument goes for git/mercurial as well I think, so no winner/looser here

/Kuddel

I disagree with subversion being good for branching/merging. I'd say it's adequate, but one of the things that I dislike about subversion is its design of "a branch is a copy operation". It doesn't really work properly the way that branching should, and if you do anything that's got large merges in then it just descends into chaos. Git's merging is far superior. And tagging is terrible in subversion - you should not be able to modify a tag! But I do agree with you that git's revision number is a lot easier to work with than git's hashes.

I've heard good things about mercurial too.

 

[Face]

Among these, which is the one you'd suggest to a noob who never used such a system and doesn't want to be intimidated?

Well, you can guess what I would say, but I didn't intent this thread to be a DVCS (or version control in general) evangelism. It is just interesting to see what the add-on development landscape looks like in this regards.

It is always good to take a look for yourself and decide for yourself. For starters, look at the "big three": Git, Mercurial, Subversion. Don't go with what is popular, though, go with what fits your needs.