penk

You're viewing

penk's journal
Create a Dreamwidth Account Learn More

Reload page in style: site light

I've just spent a few days recovering a blown out SVN database (TOTALLY my own fault - I was running in a known unstable configuration).

But, it made me think about my own choices for systems, and wondering if I should consider moving on from SVN, which I've been using for years...

So, a poll! Feel free to spread this far and wide - the more data, the merrier!

[Poll #1678037]

Flat | Top-Level Comments Only

From:

metahacker.livejournal.com

The switch to a decentralized version system is a big step, and I found it to be very helpful.

You have to stop thinking of having a central 'server' somewhere, which one the big benefit; anything that can accept ssh connections can be 'server'. On the flip side it means there is no authoritative source, only local versions, but I might argue that even with SVN/CVS/etc. there is no authoritative source, only a central server that hasn't died yet. If you want another backup, you just clone to a new place, and you can automatically work from anywhere.

Git vs. Mercurial is a taste choice, but I'd recommend using one or the other for a small project just to get the feel of it. It is SO darn easy to set up, and pretty easy to use once you understand the paradigm.

From:

penk.livejournal.com

It's that paradigm shift that I'm having a hard time with. I consider my SVN server the mountaintop to which all updates are sent. The fuzzy 'everyone is a server' model scares me.

From:

metahacker.livejournal.com

Well, you can always *declare* that one of your repos is your Server On The Mountaintop. You're just not constrained to that pattern.

I do this with a bare repo on my server (i.e. it has no local files--nothing can be 'checked out' in its space), because it's accessible from everywhere, unlike many of my satellites (e.g. the one on my thumb drive).

And if you suddenly need to move the mountaintop, that's one sync away.

From:

totient

I use SVN on a generic VPS hosting service (rather than an SVN-specific hosting service) more than anything else. But I also use SVN on private servers, and I have a small project which uses CVS with a local-filesystem repository on my laptop (not networked).

The revision control system I have most enjoyed using was Perforce. But I don't see many new projects forking out for that these days when Git gives you most of the functionality.

From:

penk.livejournal.com

Oddly, the one I've hated the most is Perforce. I find it's approach to workspace management is byzantine at best, and doesnt' really give any benefit over better-designed current systems (heck, I'll even take SVN over Perforce any day).

You need only look a the Perforce GUI client to see what they consider 'quality, released' software.

From:

vizsludraugas.livejournal.com

I've been using Subversion for a while, but I'm probably going to change to git in the not too distant future-it has a lot of features I like, and most of the people I know who have made the change swear by it.

From:

nathanjw

At work I'm using Git and Perforce (for different projects). Git scales up poorly with any workflow other than cherry-picking from the top down; having a hundred active developers pushing to the same master repo is a recipe for frustration, but having a master repo is a requirement for having reproducible builds.

From:

penk.livejournal.com

This is my prime concern with Git. I think the fanboiz hackers love git, but they may not be in the best space to decide what's good on a large scale. :-/

But, I also see the way the wind is blowing :(

From:

qwrrty.livejournal.com

The CVS manual (http://ximbiot.com/cvs/manual/cvs-1.11.23/cvs_10.html#SEC94) includes this advice:

"People, especially people who are familiar with reserved checkouts, often wonder how often conflicts occur if unreserved checkouts are used, and how difficult they are to resolve. The experience with many groups is that they occur rarely and usually are relatively straightforward to resolve.

The rarity of serious conflicts may be surprising, until one realizes that they occur only when two developers disagree on the proper design for a given section of code; such a disagreement suggests that the team has not been communicating properly in the first place."

In other words, there are some issues which still really need to be dealt with as policy, not just technology. The revision control system can certainly provide you with tools for managing checkin conflicts, but none of them are going to be a magic bullet.

This is not really to disagree with you that git scales poorly to some of those workflows: just that I suspect the Git hackers would say that that's a matter that needs to be resolved by policy and not by code. Lord knows I'm not inclined to defend Git, but I do think that's a pretty sensible position overall.

Edited Date: 2011-02-09 05:11 am (UTC)

From:

nathanjw

The trouble is that I think Git has the opposite problem of CVS in this regard. CVS permits distinct files in the same repository to be modified by different users, even if that causes a semantic conflict, and that's the level that requires policy intervention to handle sensibly. Git's "you must be entirely up to date before you can push" stance doesn't allow you to resolve that at a policy level; it makes it technically hard for many people to push. Our project is broken down into about 150 distinct git repos largely for this reason, and that solution sucks, too, since then you can't do single commits across multiple repos. The Android repo tool (which we also use now) attempts to make the multi-repo case work a bit better, but it's still a hack.

From:

feste-sylvain.livejournal.com

Honestly, Subversion is used by too many projects to ignore it. Pretty much all serious developers have to know it. But that's no reason to use it on your project.

I'd go with SVN only because other contributors would be likely to know it already. But I'm open to others (and if I weren't, I'd still be arguing for RCS against CVS).

From:

dr-memory.livejournal.com

I'm slowly, slowly getting to like git, but it's a very different model from anything that I've used before, and I'm not 100% sold that it's really such a process improvement for anyone who's name isn't "Linus Torvalds". You really do have to have an official authoritative server of record, whether that's The Dude Who Owns The Release or GitHub or whatever, so IMHO a lot of the hype over its 'decentralized' nature is overblown. But being able to juggle multiple branches in a single client view is kinda nice, although the cli and terminology makes me want to throttle people...

From:

nadreck.livejournal.com

My vote is either Git or Mercurial. There are some pretty fantastic resources out there for both.

Start here: http://hginit.com/

It's written about Mercurial, but 95% of it applies to Git as well.

Also: http://www.youtube.com/watch?v=IY8TG1AOz3A (this is a friend of mine giving a talk about Git to a bunch of Drupal developers, because Drupal is switching to Git).