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.
git
>>2
Why?
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:
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.
>>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.
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.
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.
>>3 three things:
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.
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.)
>>8
It's "already won"? DVCS software is a popularity contest?
People like you piss me off.
>>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.
>>10
i think there's a darcs <-> svn thing too.
yeah, suspicion confirmed: http://wiki.darcs.net/DarcsWiki/Tailor
> In contrast if you use SVN for version control, everyone has to use SVN for version control.
Personally I use SVK.
>>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.)
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.
>>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.
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.
>>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.
>>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.
"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.
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?
>>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.
What are we arguing about and who gives a crap?
>>22
Fanboys.