Which Version Control System? (23)

1 Name: #!/usr/bin/anonymous : 2007-12-14 12:27 ID:rRHXNVK0

Which VCS do you prefer and exactly why? Subversion, Git, Bazaar, Mercurial.. anything else worth looking at?

Bazaar looks nice to me. Previously I worked with Subversion, but now I'm searching for something with a different workflow.

2 Name: #!/usr/bin/anonymous : 2007-12-14 13:36 ID:y+YsP4Bk

git

3 Name: #!/usr/bin/anonymous : 2007-12-14 14:33 ID:Heaven

>>2
Why?

4 Name: #!/usr/bin/anonymous : 2007-12-14 15:24 ID:8INmBj/G

I LOVE darcs. It kicks ass. It's extremely simple and low maintenance, never gets in the way. In fact it's so lacking in bureaucracy that I can even use it on little ~500 lines of code projects (and I do).

When I do record or revert, darcs asks me individually about every change. This is great. Even if I've made several changes, I can just record one at a time which makes it easier to track later. There's none of those awful SVN commits where the description is something like:

  • Change the foo constructor to accept bars
  • Fix the damned compiler warnings
  • Speed up pixel thrusting by inlining a matrix calculation
  • [... 8 other things ...]
  • Probably some more stuff I'm forgetting

And then you have no way to tell what was done without a diff. Those are so lame. Also with darcs, you don't even have to set up a server. darcs is the bomb.

5 Name: #!/usr/bin/anonymous : 2007-12-14 17:18 ID:zO93NB0Q

>>4
I'm looking at Bazaar for the same reasons.. small, simple, flexible, doesn't get in the way. Have you, or anyone else here, used both? A short comparison would be great.

6 Name: #!/usr/bin/anonymous : 2007-12-14 18:20 ID:S178EZrx

Not sure if this is saying anything, but I use Mercurial for a pet project. I initially used CVS and then Subversion but didn't like the central repo design very much. When I wanted to put some other small things in there, I had to move them to the hierarchy instead of just initializing a new repo wherever I currently was. It was only a few commands, but even they were too much of a hassle for me. It just felt too heavy-weight for my purposes.

I don't remember how I came to DVCSs but I made myself a sketchy and very subjective overview of the most popular ones.

  • Darcs seemed innovative and awesome but had some fundamental design flaws that made me wary of using it, even though I probably would have never hit the resulting bugs (afaik, they will be addressed with version 2.0.0 which has gone into testing recently. Might try it again then). Also, I didn't find the documentation/tutorials that good.
  • Git's interface just seemed too complicated to me. Too many commands, too many things to keep in mind. I hear its CVS/Subversion gateway is top-notch though. Documentation is now extensive, but... hum. I don't know.
  • Monotone had a strange database thingy to store stuff. And the manual was overly verbose to explain the workflow. Turned me off somehow.
  • Mercurial looked simple and powerful. Its readable hands-on tutorials finally sold me (e.g. made it clear to me that branching is nothing more than copying a repo to a new place for independant development and then merging changes back later. Darcs' documentation left me confused on this point).
  • Bazaar looked inferior to Mercurial for whatever reason, so I avoided it :P

I don't do much programming anymore but still like Mercurial. I guess that it doesn't matter what you use for small projects, since the above DCVSs will do just fine. Just use whatever appeals to you most.

7 Name: #!/usr/bin/anonymous : 2007-12-14 18:25 ID:y+YsP4Bk

>>3 three things:

  • it's fast. really fast.
  • tools to help make the commits specific. I frequently fix two things at once- and want two commits, but don't want to do them one at a time. git makes this very easy.
  • easy merging, really easy. I never branched experimentally before using git.

hg is similarly fast, but cherry-picking out of other people's branches is harder. darcs has the interactive patchset building, but is slow as hell. monotone has easy merging, but it's so slow that checking out both branches and copying files manually is actually faster.

8 Name: #!/usr/bin/anonymous : 2007-12-14 21:44 ID:DBi6nS3I

git is not only blazing, incredibly, ludicrously fast, but it has the largest development community of all the open-source version control systems around today. In other words, it has already won. And you know, I don't really mind all that much!

The theoretical possibility of a SHA1-namespace clash remains in the background. However, the Linux tree has like, what, less than a million objects? And a single SHA1 hash is 160 bits long. Even accounting for the birthday phenomenon, I don't think there's realistically ever going to be SHA1 clashes in git.

(Though I think the subprogram that writes new objects to a repository checks hash matches, that they're indeed the same data as would've been checked in. So there's no breakage even if the once-in-a-lifetime collision came up.)

9 Name: #!/usr/bin/anonymous : 2007-12-14 23:05 ID:Heaven

>>8
It's "already won"? DVCS software is a popularity contest?

People like you piss me off.

10 Name: #!/usr/bin/anonymous : 2007-12-15 19:33 ID:y+YsP4Bk

>>8 DVCS isn't like RCS, CVS, or SVN. Two people can both use different DVCS systems and cooperate- one user can use darcs, another can use git. In contrast if you use SVN for version control, everyone has to use SVN for version control.

now git does have some features that make it superior to other systems. The only complaint I've heard about git is that it's hard to use under Windows. I don't care about them.

>>9 There is a remarkably practical reason to use git: You can export to SVN or CVS so people can anonymously pull from you very easily. This means you can use git all you like, and you don't risk alienating other people because everyone knows how to pull from CVS.

Even if you decide to use another VCS (for whatever reason), checking in through git will make it easy to forward it to anonymous users.

11 Name: #!/usr/bin/anonymous : 2007-12-15 20:45 ID:8INmBj/G

>>10
i think there's a darcs <-> svn thing too.

yeah, suspicion confirmed: http://wiki.darcs.net/DarcsWiki/Tailor

12 Name: #!/usr/bin/anonymous : 2007-12-16 12:19 ID:Heaven

> In contrast if you use SVN for version control, everyone has to use SVN for version control.

Personally I use SVK.

13 Name: #!/usr/bin/anonymous : 2007-12-16 22:58 ID:DBi6nS3I

>>9
It's not as much about a popularity contest as it is about which is best right now, and which one will be consistently maintained for the years to come. Popularity I could care less about -- especially given that Subversion seems like the better, shinier CVS everyone seems to be into these days. (bleah.)

14 Name: #!/usr/bin/anonymous : 2007-12-17 05:06 ID:8INmBj/G

Well, darcs clearly has enough critical mass it's not about to disappear. Beyond that, I can't see how having more developers is a plus; it might even be a bad thing, too many cooks and all.

I personally barely work on anything aside from personal projects, but that Tailor program looks like it should keep interoperability working well enough. Actually, I do work on one SVN project, and had not considered using Darcs + Tailor, but I really should look into that.

15 Name: #!/usr/bin/anonymous : 2007-12-18 17:41 ID:DBi6nS3I

>>14
Just what on earth are you smoking? Too many cooks?

When someone thinks of something clever to do in the context of distributed version control, they'll up and implement it on the VCS package that they're most familiar with. Much of the time this turns out to be git, being as its fundamental data structures and repository format are blindingly simple. Therefore more developers becomes more features, which is better than fewer features.

Also, last I tried Darcs still has significant issues with getting into deep recursive bogs which it cannot climb out of in finite time. That's hardly what I'd call production quality.

16 Name: #!/usr/bin/anonymous : 2007-12-18 18:03 ID:8INmBj/G

Personally, I never find myself wanting new clever features. I'm using a 5 minor versions old darcs, in fact, and it does everything I need it to do. "More features" is definitely the Linux way, but that can get messy ;)

I ran into that recursive thing once; believe it was because I had one copy with Windows newlines and one with Unix newlines that I was trying to merge. Worked great once I fixed the newlines. According to >>6 and some blogs I looked at recently, Darcs 2.0 is supposed to solve that problem completely should it be an issue for you.

17 Name: #!/usr/bin/anonymous : 2007-12-23 07:56 ID:Heaven

>>15
"Too many cooks spoil the broth"
This is a well recognized phenomenon in software engineering (and every other human endeavour involving more than one person).

What actually happens in your proposed scenario is these hundreds of would be git developers go and and write their features and some of them wander off somewhere else and their pets become unmaintained and trying to follow the git mailing list becomes impossible and git's heads keep growing and growing until you have an unmanageable trainwreck of bugs and complicated code.

18 Name: #!/usr/bin/anonymous : 2007-12-25 13:50 ID:DBi6nS3I

>>17
You do realize that the very nature of distributed version control makes it trivially easy to ignore half-assed patches until they're ready? There are very good ways to prevent the too many cooks effect, you see.

Not to mention that you haven't so far shown that this scenario was likely in git's case. I guess some people have a tendency to prefer a One Strong Leader, you know, Stalin and Hitler and Bush and so forth, to a bunch of clever people who know their shit.

19 Name: #!/usr/bin/anonymous : 2007-12-25 17:58 ID:8INmBj/G

"More features" sucks, honestly. In experimental software, fine, but I want a VCS that's stable and well-understood.

Just my opinion, though, and if you disagree, well, there's git and a bunch of other VCS systems to make you happy too.

20 Name: #!/usr/bin/anonymous : 2007-12-26 07:46 ID:Heaven

>>18
Not to mention that you haven't so far shown that this scenario was likely in git's case. I guess some people have a tendency to prefer a One Strong Leader, you know, Stalin and Hitler and Bush and so forth, to a bunch of clever people who know their shit.
Did you seriously post that? Unironically?

Things don't work the way you think they work. Influxes of new members to a group don't often improve the group's work meaningfully. Expanding the capabilities and domain of a project doesn't necessarily (or usually!) improve the project. Products don't gradually move over time toward capturing complete market share forever and ever amen (and this is a good thing). Please, for the sake of everyone you will be working with, take some software engineering classes before engaging in any signficant programming project.

21 Name: #!/usr/bin/anonymous : 2007-12-26 20:15 ID:DBi6nS3I

>>20
This may be. However, you haven't shown that git development was in any way following the "vast horde of idiots" you seem to presuppose. (See, I can ignore presented arguments too!)

Regardless, I continue to posit that more developer mindshare is a better thing in a VCS than the approximately three people working on darcs. Furthermore, I claim that people who think fewer features is somehow a good thing are deluding themselves due to being heavily invested (in some vague emotional sense) in their current VCS of choice.

22 Name: #!/usr/bin/anonymous : 2007-12-27 00:55 ID:Heaven

What are we arguing about and who gives a crap?

23 Name: #!/usr/bin/anonymous : 2007-12-27 17:48 ID:Heaven

>>22
Fanboys.

This thread has been closed. You cannot post in this thread any longer.