Making Sense of Revision-Control Systems 268
ChelleChelle writes "During the past half-decade there has been an explosion of creativity in revision-control software, complicating the task of determining which tool to use to track and manage the complexity of a project as it evolves. Today, leaders of teams are faced with a bewildering array of choices ranging from Subversion to the more popular Git and Mercurial. It is important to keep in mind that whether distributed or centralized, all revision-control systems come with a complicated set of trade-offs. Each tool emphasizes a distinct approach to working and collaboration, which in turn influences how the team works. This article outlines how to go about finding the best match between tool and team."
Perforce (Score:2)
Re:Perforce (Score:5, Insightful)
P4 is awesome and works great for huge repos with lots of developers.
However it is getting stale. I can't think of a single new feature added to it since I started using it in 1999.
Greetings and Salutations...
Funny...I tend to think of software more like a truck than a stalk of celery, so, staleness really never popped up on my radar. What new features would add to the capabilities of a package that you describe as "awesome"?
Not flaming, I am really curious, as I have done some software development myself, and, wonder where the line is between actually adding good functionality to a tool, and "creeping featuritis" that adds bells, whistles and complications, but no real increased usability.
regards
dave mundt
Re: (Score:2, Interesting)
Off-line development is the first thing that come to mind.
Its also single-centrally managed server, which is painful for distributed development (but perhaps good for companies). There is P4Proxy, but that is readonly. Remote users on the other side of the world don't have the best experience.
I could list many other things. SCM has grown significantly since 1999, P4 hasn't.
Re: (Score:2)
"getting stale."
How has the task of revision control changed over time to warrant adding new features? Did it ever occur to you that Perforce is a Stable product and many of us enjoy working with it just as it is?
Re: (Score:2)
Dramatically ! Distributed revision control is fairly new, and taking over fast. I'm not sure if the summary is correct that git and mercurial (distributed SCM Tools) are now more popular than antiquated client/server SCM tools like CVS, Subversion, perforce, etc.. but it certainly should be true because the distributed paradigm is a major improvement. You should research this stuff. You'd be amazed at how much is
Re: (Score:2, Interesting)
P4 is fast but don't be mistaken it too has some reasonable failings
is performance/reliability is terrible over a WAN
lacks an integrated secure communicaiton system
no disconnected operation
no archive/shelving operations
Re: (Score:2)
TO say that you must never have used Clear Case.
Least logical? (Score:2)
How is "less logical" to function robustly under a load of hundreds of developers checking in code while build jobs are simultaneously checking out code? How "less logical" is it for a single server to be able to hold the entire code reserve of a large software company and serve it to all its users? There is no other product that will function as well as Perforce under such a load.
Re: (Score:2)
How is "less logical" to function robustly under a load of hundreds of developers checking in code while build jobs are simultaneously checking out code? How "less logical" is it for a single server to be able to hold the entire code reserve of a large software company and serve it to all its users? There is no other product that will function as well as Perforce under such a load.
I don't know if you noticed, but git seems to be doing pretty well for the Linux kernel. Admittedly, there are only thousands of developers simultaneously working on the project while many thousands of people are simultaneously checking out code to build. I suspect that p4 would rapidly choke and die if you tried to do the sort of scale and rate of development that the kernel maintains month after month.
Git and Mercurial? (Score:4, Insightful)
Git and Mercurial are more popular than Subversion? That's the big news to me, with all snarkyness aside. I best be getting out of my bubble.
Re:Git and Mercurial? (Score:5, Interesting)
Re: (Score:2)
Outside of Linux development Git is almost unheard of, but may gain popularity and although I've worked with Mercurial professionally I've yet to see it used anywhere for Open Source development, yet.
I guess I must be living in my own bubble then. Not that subversion isn't the most dominant version control system out there, it still is I think, but recently I've been using github (which uses git) and google code (which uses Mercurial) most of the time -- and I can see why someone could mistakenly think that github and google code are the only thing there is (after all, who uses sourceforge/tigris anymore? I'm sure some people still do use those repos, but I certainly wouldn't start a new open source pro
Re: (Score:2)
Given the vast numbers of CVS repositories that exist and the ease with which you can transition to Subversion, I don't think it's popularity is going to wane any time soon.
git to CVS transformation and a server that servers git repos to CVS clients exist, too.
SVN is in a weird place: it's not exactly legacy. There are certainly new projects choosing it. But almost all of those know that it's an intermediate step that'll be out the door in a few years.
There's 1 major reason to choose SVN over git: better
Re: (Score:2)
There's 1 major reason to choose SVN over git: better GUI clients.
I think SVN Apache/DAV integration is much more polished than git's. Things like VisualSVN give you out the box Active Directory integration, with a management interface to boot.
Re: (Score:2)
KDE is also currently moving to git. Currently Amarok and a few other KDE apps have switched first, to iron out any bugs.
Re: (Score:2)
No shit. Most of my conversations about revision control systems involve whether or not there is any real reason to move from CVS to Subversion. I've used SVN at each of the last few places I've worked, and in my private life, everybody seems to use SVN.
Git seems to bewilder most people I know. I think part of it may be that most of the repositories I deal with are
Re: (Score:2, Informative)
Please do. For many corporate purposes Subversion is opular, but its truly awful security models (storing passwords silently in your local $HOME/.subversion/auth direcotory by default, unencrypted, and refusal to publish workable configuraitons for purely anonymous access), coupled with its designers absolute refusal to support deleting contents from the repository (even if they're accidentally stored DVD images or copyrighted code) leads to a very harsh conflict between the idea of "source control deletes
Re:Git and Mercurial? (Score:5, Insightful)
I don't necessarily disagree with you, but in places I've worked, if we removed code in such a fashion and an audit found out about it, we'd get pummeled. Especially if it was discovered after a public release. It's one thing to ship code copyrighted by someone else, it's something completely different to go about covering up the fact.
So I'm torn on this "feature."
Re:Git and Mercurial? (Score:5, Informative)
That is one great feature of Subversion: absolutely no way to screw up stuff that was committed. Revision control is about keeping track of stuff, any model that allows a user to remove information from a repository is a disaster quietly waiting to happen; sorry you did not understand that.
If you absolutely need to remove something from a SVN repository, you can do that with svndumpfilter, meaning you have to ask the repository's administrator. That's a good safeguard against accidental deletions.
For "cleaner code" you just need svn delete.
+1 Informative (Score:2)
Please mod parent informative, because it absolutely is.
Re: (Score:2)
Its not so much a refusal to support full deletion than a problem that the task is difficult - subversion was designed not to delete anything placed in the repository (except as a awkward admin task), and now everyone realises that it is desirable to do this occasionally, they're finding it'll be a hard job to do - so it gets put off until next the major version. Its been put off like this since v1.2 IIRC.
Google for svn obliterate for the full details, the svn docs has a spec for the work. If you want to wo
Re: (Score:2)
Call me crazy, but exactly how is this insecure? It's the filesystem's job to provide security, hence the access for the directory is 700. Exactly what kind of scenario would an unauthorized person having access to your home folder not already be enough of a security breach so as not to matter? Even then, you can turn off password caching entirely if you want if you're really worried about it (store-password
Re: (Score:2)
Git and Mercurial are more popular than Subversion? That's the big news to me,
For more recent projects, hell yes, subversion still has the larger installed base at the moment, but the speed with which git is being adopted is scary.
After learning git myself though I can see why, it's just a superior system. Even when working with SVN repositories I now use git because of the better functionality.
Re: (Score:3, Insightful)
Mercurial is a distributed system, Subversion is centralised. They suit almost totally different workflows and teams. If you're a large group of Open Source developers in different countries and timezones Mercurial may suit you. If you're a small group of developers in the same office doing rapid development, Subversion may be better for you.
Re: (Score:2, Insightful)
This can only be said by someone that hasn't used a distributed system.
Even if you are the only coder, a distributed system is still better since you're going to have your version, and the version on the server, and you want to be able to play about with your local version before pushing to the server. That's the sort of thing that git/mercurial are excellent at.
Re: (Score:3, Insightful)
This can only be said by someone that hasn't used a distributed system.
Even if you are the only coder, a distributed system is still better since you're going to have your version, and the version on the server, and you want to be able to play about with your local version before pushing to the server. That's the sort of thing that git/mercurial are excellent at.
Wouldn't distributed and centralized version control degenerate to the same thing in the case of a single user? I've never used a distributed system, what difference would there be in that case?
Re: (Score:2)
Say you offer the repository to the world, so that your users can get your latest work to try it out.
And now you want to do a large refactoring of your code. You could do that as a series of commits locally, test it etc, and then push to the server in one go. Rather than pushing the changes incrementally and leaving the system in a broken state in the mean time.
Re:Git and Mercurial? (Score:4, Insightful)
you can do that with either centralised or distributed systems, i fail to see your point.
Re: (Score:2)
We're talking about the single-user case here.
Re: (Score:2)
Subversion calls this a feature branch. You branch the trunk, which stays open to the public. You make regular commits to the branch, and when the large refactoring is done in the branch, you reintegrate the branch into the trunk. The trunk remains stable during the whole process.
How is it different with a distributed system?
Re: (Score:3, Interesting)
If you want a policy that everything has to be in branches, then you can do that in git. In fact it's much easier in git than svn.
> What it boils down to is that a distributed system allows a developer to go hide in a cave for a while whilst under the illusion that stuff is safely checked in.
With SVN, a developer can go hide in a cave for a while without ever committing stuff. What's the difference?
The part about committing as early as possible doesn't really make sense to me. If you have two group wi
Re: (Score:3, Informative)
There are only a few use cases where single user distributed and centralized revision control systems differ.
1. You can carry a local repository on your laptop and commit. You do not then need to sync to the master repository before continuing work there. (Typically in a distributed system there is one repository that is given the status of master - this avoids issues where two teams might be syncing amongst themselves but both are blissfully unaware that there is any other work happening in the same area o
Re: (Score:3, Informative)
I'm not even a coder but I already love git for getting the kernel sources. For years I have been downloading incremental patches from kernel.org but now I can update my tree with a single command. Just this weekend I
Re: (Score:2)
"you want to be able to play about with your local version before pushing to the server"
Maybe your manager doesn't want you working with your local version and then your work being unaccountable. Maybe your manager preferes you working on a personal branch on the centrallized repo.
Re: (Score:2)
> A large scale commercial development team, for example, is much more likely to be structured in a way where Subversion would be a better solution.
I work in a large scale commercial development team and we use git. I still see no possible advantage of SVN over git from that structural point of view.
The plugins and clients for git will grow rapidly I'm sure.
The backup thing though has to be joke. Every single person that checks out the code is making a complete backup.
Re: (Score:3)
I've worked in commercial development teams where a distributed system would not have worked, at all, due to external constraints and processes imposed by management.
What sort of constraints? Just wondering.
Every single developer has a local repository with local changes. If you're doing things right your developers are only pushing their changesets to the central repository every couple of days. You have to ensure those local changes are backed up in the meantime.
Or you simply don't bother. Losing one developers 'couple of days' work usually isn't a big concern. It's common for svn users to also have several days worth of work uncommitted.
Although with git you can get people to trivially push as a branch to the server (git push origin master:mybranch) which is much more difficult in SVN.
Re: (Score:2)
I don't know what sort of developer you are, but I commit to my local branch several times a day, simply because I know I fuck up a lot and might overwrite changes I made earlier or rewrite code that I'm modifying to find a bug in.
It's not uncommon for me to check in once an hour.
My changes can get put onto the server many times a day with subversion. Not so much with git, SVK, or Hg.
Re: (Score:2)
"What sort of [managerial] constraints? Just wondering.
[...]
Losing one developers 'couple of days' work usually isn't a big concern. It's common for svn users to also have several days worth of work uncommitted."
*That* kind of managerial constraints. Losing 'couple of days' of development work *is* a concern; having several days worth of work uncommitted *is* a concern.
Re: (Score:3, Interesting)
> Using a distributed system such as Mercurial would have made this near impossible as there would be no way to stop someone cloning a developers local repository.
How is that different from just copying a developers svn copy? You wouldn't get the history, but you would get the code...
The other things are also possible. See git pre-commit hooks.
Re: (Score:2)
With a DVCS the developer just has their own branch (which can be on a central server) and they can commit whenever they like and have everything backed up -- branch management is so easy with most DVCSes that this is a non-issue. Now, if the developer is disconnected for long periods at a time, then you might have a point... but in that case a centralized VCS is even worse. At least
Re: (Score:2)
With a distributed system, you can push it to a central server to an own copy (each developer has it's own url to keep a backup) at any time, like the end of the day.
You can't do that with a centralized system.
Maybe it can even be used by others to pull from.
Re: (Score:3, Insightful)
I disagree. CVS/svn worked well in my last workplace in two use cases:
1. A project which largely has a single developer working on it. (Lots of those.)
2. Something with several developers, but very slow code changes and much discussion before even those. (Much of the stuff us sysadmins were doing.)
Any version control is a vast improvement on none, and svn is fine at being svn. But it's the last of its line.
Re: (Score:2)
It's pretty much impossible to corrupt git, since every commit is SHA1 checked.
Run: git reflog
and it shows you every change that you made (commits, merges etc). You can then roll back to any point in time. Simply find the magic 6 letter SHA that git reflog gives you for which ever commit you want to go to, then:
git reset --hard SHA
or alternatively:
git reset --hard HEAD@6
to mean to rollback as it was 6 changes ago (it makes more sense when you see the output from git reflog)
(--hard will delete any uncommi
Corrupt working directories (Score:2)
I haven't fooled around much with Git, but from what I understand, unlike subversion it doesn't pollute the working copy with a bunch of trash. It is trivial to corrupt a subversion working copy and I find it one of the least stable aspects of an otherwise extremely stable system.
I understand the subversion dudes are working on moving their trash out of the working copy. Hopefully they can get that done soon! The several times some brain-dead script accidentally ran over my working directory and messed i
Re: (Score:3, Interesting)
But that's only a 'legacy' problem. Today, going from no version control straight to Git/Hg is much easier than even your first step -- and saves you from having to unlearn all that intermediate junk.
Re: (Score:2)
You can work on your project on the bus (or at home after you move into a new apartment and don't have internet access for a couple weeks, not this this happened a couple weeks ago to me) without worrying about hoarding changes that you can't commit yet
The trouble with this is that you have to worry about your laptop crashing, being broken or stolen. Today, with a £30 usb wireless dongle, you can commit changes no matter where you are. The lack of internet access isn't a good enough reason to advocate
Re: (Score:2)
distribute systems have advantages for developers in the same office. Branches are cheap and easy to merge in distributed systems. Keeping a branch in subversion so you can backup your code everynight tends to blow up in your face if you have a rapidly changing trunk you wish to track. It adds about 10 to 60 minutes of extra work every time I want to merge recent changes back into my private branch. I also need to share with two other developers, so just waiting to commit is not a viable option either. They
Re: (Score:2)
Re: (Score:3, Informative)
Yeah. I know. In fact I did just that at my last job when we implemented Mercurial. The problem is training developers to push their local changeset to the central repository and from stopping developers pulling from someone else and not the central repository. There was a least one incident a week where a conflict arose due to developers doing things like that which led to divergent codebases which required signific
Question about subversion (Score:2)
I have experience using rcs and it seemed good enough. Now I'm currently using subversion that someone else set up in the name of progress (not my decision). My problem is it's cluttering up my working directories with meta data, plus I run into consistency problems as I'm moving and merging code from temporary experimental folders and other teams folders that are not in the same repository. All of this was perfectly fine with rcs (I would just check out something, make whatever changes I needed to and chec
Re: (Score:2)
Re: (Score:2)
Copying code between repository sounds like a bad idea to begin with - it means that you are losing the history of the files.
Also the temporary experimental folders should be done with branches. Unfortunately any centralised system sucks at doing branches, compared to git or mercurial.
Honestly, I think you should spend a few hours learning svn, and then get "git svn" and learn and use that.
Re: (Score:2)
svn is a vast improvement over rcs and your use case sounds fairly common so I'd guess that you are doing something wrong.
As a sidenote, terms like 'experimental folders' and 'other teams folders' sound really bad: if your source control was sane you wouldn't need 'experimental folders'... What you really want is a tool that makes branches so cheap you can always create new ones... Any time you need to experiment, you just create a new branch on your local repo (and you can work on the main branch at the sa
Re: (Score:2)
To get a "clean" copy of a directory, use the "Export" command from your local repo. Subversion is nice because it limits the number of commands that you can (and would need to) run but names them as strangely as any other Revision Control System. You do need to produce process for how branching is done.
Errata (Score:5, Informative)
Because Subversion offers working out of a shared branch as the path of least resistance, developers tend to do so blindly without understanding the risk they face. In fact, the risks are even subtler: suppose that Alice's changes do not textually conflict with Bob's; she will not be forced to check out Bob's changes before she commits, so she can commit her changes to the server unimpeded, resulting in a new tree state that no human has ever seen or tested.
This statement is incorrect. Subversion requres you to update your working copy before committing whenever you have modified a file that has changed in the repository.
Re: (Score:2)
Additionally, he mentions (at the end of the article) that distributed systems have issues with old projects that have long histories as an area for further research. He doesn't discuss bzr, which has a SVN-like mode for working with repositories when an overly-large history size is a real issue. He also doesn't discuss git clone --depth which may help with such issues. The git documentation is overly conservative when describing what you can do with a depth-limited repository -- there are plenty of conditi
Re:Errata (Score:4, Insightful)
Yes and no. It is possible to only update/checkin at a certain level in the directory hierarchy, and miss a change to a header outside of the scope you are interested in. You have to be slightly beligerent to get into such a situation, but it can happen.
Re: (Score:2)
I guess I misunderstood. He must have been talking about the project standpoint where alice updates foo.c and bob updates bar.c. I don't think they have to see each other's changes to commit. But if they touch the same file, even though their changes don't textually conflict, then they do have to see each other's changes.
Re: (Score:2)
You don't need consolation for this; you can always revert back to Bob's revision and have Alice go back and make sure her check in isn't overwriting Bob's code.
Re: (Score:2)
No, SVN will never commit changes if your working copy is out of date. it may merge the repository changes in automatically for you, but the OP was wrong - it will not overwrite already committed changes.
No they don't. (Score:5, Informative)
Each tool emphasizes a distinct approach to working and collaboration, which in turn influences how the team works.
Ok, yes, some tools do. For example, subversion supports trivial branching, but sucks at merging, so it encourages people to work on a common "trunk" branch. It also only supports a central server, so it "encourages" developing with a central server.
Git, on the other hand, "encourages" people to not put multi-gigabyte files in version control.
However, Git can be used to talk to an SVN repository. It can also talk to a central repository, or work purely via ssh between workstations, or with something like Gitjour, in a truly distributed fashion. Github is a strange and wonderful mutation of the two.
Perhaps, by making branches and merges so awesomely fast, Git "encourages" lots of little local branches, and keeping a neat patch history. But to sum it up:
SVN can handle large binary files and Windows better than Git, and is better integrated into IDEs.
Git is better at everything else, ever. Seriously -- 99% of projects that are hosted on SVN would make more sense on Git.
Re:No they don't. (Score:5, Interesting)
When I first looked at git, it wasn't even clear how simple revision control tasks could be done, e.g. simply checking in a file, or reverting changes to it. Looked like you had to deal with bizarre syntax and long hex numbers for the simplest things (and it's not just because it's distributed, as mercurial was much more straightforward). I assume that's changed as people aside from Linus actually use the thing, but it was very off-putting in the beginning.
Re:No they don't. (Score:5, Informative)
It has changed, somewhat -- but mostly, I think there's just better documentation.
But, for example...
Looked like you had to deal with bizarre syntax and long hex numbers for the simplest things
That is pretty fundamental to the design -- it's a SHA1 hash. It's also not incredibly difficult -- cut and paste. When your SVN revisions hit four and five digits, they don't really have much more meaning than that hash, do they?
Generally, you learn to use relative terms, instead -- for example, HEAD^ to refer to the revision just behind HEAD.
mercurial was much more straightforward
I thought so, too...
I think I tried mercurial, and then bzr, and eventually settled on Git for three reasons:
I should clarify that last part... Maybe some things are cryptic, and I'm sure I don't know all of the possible commands I could run -- but at a very basic level, I know exactly what's going on, just like I did in SVN.
Just for fun, here's the data model in a paragraph: There are commits. Each commit has a parent commit that it includes, except for merges, which have two parents. A branch is just a pointer to a commit.
That's it.
And knowing that, everything else starts to make sense... but it's more than I want to get into in a Slashdot post.
Re: (Score:2)
That is pretty fundamental to the design -- it's a SHA1 hash. It's also not incredibly difficult -- cut and paste. When your SVN revisions hit four and five digits, they don't really have much more meaning than that hash, do they?
Well, except that SVN revision numbers are in order. Could you tell at a glance which of two binaries with the git SHA1 hash in the filename was newer? What about with an svn revision number?
To me, it would make more sense if there was an incremental part to a git changelist id, even if it was "number of seconds since 2000" or something else unreadable, as long as you could ask someone "which revision crashed" and get back an answer you could easily use to tell if they were up-to-date or miles out of date.
Re: (Score:3, Informative)
Well, except that SVN revision numbers are in order. Could you tell at a glance which of two binaries with the git SHA1 hash in the filename was newer? What about with an svn revision number?
You may wish to investigate the git describe command. For example:
[peter@harrington git (master)]$ git describe
v1.6.3.2-225-gb836490
The output contains the latest annotated tag, the number of commits since that tag, and the first 7 hex digits of the current commit hash prefixed by a "g". All the information you need to quickly or precisely identify a revision.
Documentation is here [kernel.org].
Re: (Score:2)
Could you tell at a glance which of two binaries with the git SHA1 hash in the filename was newer?
No, but I could tell with a quick 'git log' of each.
Can you tell me when I would ever, ever need this? I never look at revision numbers outside of a log anyway. The last time I can remember caring what those numbers were, or holding them in my head for longer than a copy/paste (if that), is when I had to manually feed revision numbers into 'svn merge'.
Well, guess what? 'git merge' is smart enough to not need that. The "merge tracking" feature of SVN that's supposed to give it similar functionality also slow
Re: (Score:2)
This is a stupid "me too" post, but hopefully it will lend credence to what you say.
I originally used SVN because at the time there weren't any other credible options. I moved to bzr because I wanted distributed version control and bzr's syntax seemed easier than Git. Now I'm in the processes of moving over to Git. Git's documentation has vastly improved and that's a big reason for my change. I can't even really understand why I thought it was more difficult than bzr now. I also think that if people tr
Re: (Score:2)
The SHA1 hashes may look scary at first, but it really is the best approach.
This is the only thing I'm not sure I agree with -- SHA1 is kind of weak by now, and it was already old-ish when Git was written.
But I definitely agree on that much -- I prefer a globally unique number (though maybe a GUID would be better?) to a kludgy attempt at preserving revision numbers.
There was actually another reason I preferred bzr -- it's written in Python. Git is written in C, Bash, and Perl, which means a lot steeper of a learning curve if I were to ever hack on it. But I'm starting to realize I'
Re: (Score:3, Interesting)
There is an occasional conflict, but you can't always avoid that.
Git avoids that a lot better than Subversion does. Yes, there's an "occasional" conflict, but much more rarely.
Call me a die hard, but I wouldn't trust Subversion's automatic merge feature. I do it all by hand
Yes, I've done that...
Doing it all by hand sucks -- it's a lot of manual effort to make sure you know exactly what you should be merging, and it still takes far longer to do that. Doing it with SVN's merge tracking sucks -- we had it to where it was taking half an hour, and could still fail.
I mean, I liked the model. I liked having a deep understanding of what it was doing.
But even by hand, even tr
Re: (Score:2)
You can branch to your heart's content in Subversion.
Which is useless if you can't merge.
Git branches are not only much lower cost at the beginning (the command runs faster and is easier to use, and other users don't have to know about your branch until it's ready), but they merge much more easily.
The only difference is that Subversion is centralized, so you need a network connection to the server to commit.
Well, and that if the network connection or the server goes down, I can't work.
But to say that distributed is the only good thing about Git would be like saying that centralized is the only good thing about SVN.
Which would you rather use, SVN or CVS?
Then you can und
"More Popular"? (Score:3, Insightful)
> Today, leaders of teams are faced with a bewildering array of choices ranging from Subversion to the more popular Git and Mercurial.
I think you might be confusing Internet "buzz" with popularity.
TortoiseSVN (Score:4, Insightful)
I am a bit jealous of some Git features, but the place I work -- and me for my personal projects -- use SVN for one big reason: TortoiseSVN. It is a great interface to version control and not everyone (probably the majority) who needs to contribute is a programmer, or has any idea about command line interfaces, ssh, branching, merging, etc.
I am aware of TortoiseGit, but it has not reached a stable release, so it is not up for consideration in a serious environment.
There are other things to keep in mind too; SVN is much more tailored to our repo structure than Git, so that's a big plus for SVN -- at least for us.
Re: (Score:2)
I am a bit jealous of some Git features, but the place I work -- and me for my personal projects -- use SVN for one big reason: TortoiseSVN. It is a great interface to version control and not everyone (probably the majority) who needs to contribute is a programmer, or has any idea about command line interfaces, ssh, branching, merging, etc.
I am aware of TortoiseGit, but it has not reached a stable release, so it is not up for consideration in a serious environment.
There are other things to keep in mind too; SVN is much more tailored to our repo structure than Git, so that's a big plus for SVN -- at least for us.
Tortoise is also cross-platform, for when that's important. And there's even TortoiseCVS, if that's your style.
Re: (Score:2)
Tortoise is also cross-platform, for when that's important.
I beg to differ.
From http://tortoisesvn.net/node/58 [tortoisesvn.net]:
TortoiseSVN is only available on Windows.
That page lists clients similar to tortoise for other OSes, but the real, genuine tortoiseSVN is Windows-only.
Re: (Score:2)
I work for a company which switched from CVS->gnuarch->Mercurial (For the gnuarch, switch it was when we were small and the lone diva developer made the decision for us) (For the mercurial (Hg) switch we evaluated SVN, Git and a few others before settling on mercurial)
Hg has made merging a dream, and everything else is really easy. The biggest headache from the dev's was for a period of about two weeks where they had issues with the extra "Push" step.
I believe that Netbeans and Eclipse have Hg plugi
Re: (Score:2)
even if your company uses a central SVN repo, you can still use git yourself, 'man git-svn' it allows you basically all of the advantages of git without any svn users even knowing that you're using it.
When you get used to the workflow you'll wonder how people ever used svn.
Re: (Score:2)
When you get used to the workflow you'll wonder how people ever used svn.
No they won't - SVN pretty much sucks all around. There'll be no wonder if Git's actually better. I've considered looking over Bazaar and AccuRev, but the latter costs too much, and I ran out of time for the former.
Re: (Score:3, Informative)
Ugh, I can't stand Tortoise. It just *kills* the speed of my file-open/save dialogs. In exchange for a few labels (and not in visual studio! just the explorer) and right-click commands (hint: a menu and some dialog boxes do not constitute a GUI) I literally go get coffee when the dialog box is loading my checked-out repo.
psvn.el for Emacs, however, is an absolute dream. I see my repo (or subfolder thereof) as one dired-like list. diff, checkin/update, etc. are live and just update my buffer.
how about the tps report system for each change (Score:2)
how about the tps report system for each change the PHB makes a big fuss about it when you don't do them and gets on your ass when you take the time to do them and your other work fail behind when you take the time to do them.
No mention of ClearCase? (Score:4, Informative)
What I find interesting is there's no mention of ClearCase. Maybe the author is unaware of it, or considers it obsolete? Then again, the author didn't seem that experienced with the debacles into which one can get with revision control SW. The example he posits is the least of the problems which can crop up.
I've used both ClearCase and CVS. First, CVS:
Now for ClearCase
Now, granted, a lot of FOSS products are not trying to be SEI level 5*. They don't have to demonstrate a repeatable process. The often don't incorporate bug fixes into older releases, or maintain several concurrent branches of the same codebase. It is also important to show which
Re: (Score:2)
Essentially everyone who knows anything about modern version control considers CVS obsolete. Many of the things you discuss in your comment were considered, discussed, and resolved years ago, though different systems went about solving them in different ways.
SVN is essentially CVS with most of the annoying problems fixed, and several other advantages besides. Most other systems are completely different. There are even many people who consider any version control that isn't distributed to be obsolete.
It's ra
Re:No mention of ClearCase? (Score:4, Insightful)
Essentially everyone who knows anything about modern version control considers CVS obsolete.
Clarification: everyone who thinks they know everything about modern version control considers CVS obsolete.
CVS still has advantages, in my opinion:
- simple underlying storage structure that any administrator can understand
- ability to simply administratively repair obscene or damaging check ins (investigate the cvs admin -o command, few other version control systems can do this)
- simple file numbering scheme
At the end of the day your needs may be more complex (regular branching, regular directory moves, etc) but in some commercial situations simplicity and ease of administration can be valuable points (and I think often outweighs the perceived benefits of SVN).
As for Git with it's advanced learning curve of at least a week, sometimes you have not just programmers contributing to a project but front-end designers, template producers, who have never seen a version control system in their life. Subjecting them to Git can be both cruel and potentially uneconomic - particularly if they are all on short term contracts.
Re:No mention of ClearCase? (Score:4, Insightful)
I use Subversion on a daily basis, and I believe everything positive you said about ClearCase holds true for Subversion, except point 9. There are some philosophical objections to 9 (you should test the resulting code before committing it anyway), but I don't know if it's a design decision or a missing feature.
That's not to say that Subversion doesn't have problems of its own though, but using CVS as a representation of the state of version control systems is like judging proprietary software on the basis of Windows 95.
Re: (Score:2)
Git an Mercurial are fundamentally different from the others you mentioned. They are distributed version control systems. You are free to set up your own topologies and methods for synchronizing. The biggest disadvantage is in not being able to easily checkout partial trees. This affects your workflow. IMHO, it results in a better workflow since you are forced to decouple the release of separate projects. But I'm sure I would get some stiff arguments from some people on that point. (My main argument i
Re: (Score:3, Informative)
Nope. Moving directories within a checked out repository and committing their content will commit them back from where they were checked out.
His "save overwrite stuff" issue is probably due to him loading a file in his editor, updating the underlying version, and saving the file. If he uses a shitty editor, he may overwrite the changes. If he blindly commit his changes, he may have manually reverted the file. I've seen this happen with careless developers. I don't consider this a deficiency of CVS, as he ac
Clearcase. (Score:3, Insightful)
I've only tried a few revision control systems.
Of those I've tried, Clearcase is the hands-down winner function-wise, especially for the diverge-converge model of multi-programmer development.
Extremely lightweight branching. "View spec" - a little language to specify exactly what version of what you want: (Version x.y.z but override by the foobar feature development branch but override that by anything in /src/garble as of Tuesday at 3:15PM but override all with anything I've got checked out in MY development branch...). Integration into the filesystem so your tools "see" containing just what version of the sources you specified. A make variant that imports already-built objects that some OTHER developer made from the equivalent sources, rather than compiling them again, etc.
Downside: It's commercial and 'way pricey.
But if you're a commercial shop you should at least evaluate it. The functionality is fansastic.
(I hear some of the core functionality came from an open-sourced student project. I've often wondered why there isn't a FOSS clone of the important features - or if there is and I just missed it.)
Savana - transactional workspaces on top of SVN (Score:4, Interesting)
Friends of mine have open-sourced savana, http://savana.codehaus.org/ [codehaus.org] a thin layer on top of Subversion that makes it easy to do all work in private branches before promoting to the trunk. A common workflow is:
sav createuserbranch mybranch --calls svn copy under the covers to create user branch named mybranch ... normal checkins using svn commit go to YOUR private branch ... when you are ready to promote your changes back to the trunk:
sav sync -- pulls in any changes made to trunk since your private branch was created so you can test locally
sav promote -- merges your changes back into the trunk
The thing I like about this thin "workspace managing" layer on top of Subversion is that for the most part you can take advantage of existing tool support for subversion (like integrated IntelliJ Idea and Eclipse support), as all of the savana commands just call svn commands under the covers.
Re: (Score:2)
They discuss darcs, but it's too esoteric for them to understand, so they don't discuss it too much. And they don't really go into differences between git and hg (if there are any).
Re: (Score:2)
Indeed. There's nothing like a month of inspired coding that fucks up the whole codebase before you realise it won't work, to keep you in a job.
Re: (Score:3, Funny)
I'd suggest Git too. But what I really want to know is... why does it matter *which* our project chooses? Surely IDE devs and bugtracker teams could build a decent abstraction layer so that any DVCS would work just fine with them.
I think Pida just spun-off an abstraction layer at least. Hopefully people will get behind it and put an end to these silly DVCS wars once and for all.
Besides, everyone knows language wars are where it's at ;)
Re: (Score:2)
Meet DVC [gna.org]...
Talk to a lawyer (Score:2)
They understand revision control. Documents are to lawyers what code is to software developers.
Re: (Score:2)
I have found it exceptionally difficult to explain to people why revision control systems are useful. I am not talking to computer science people (sadly). For some reason people don't seem to want to spend the five minutes running through a common git tutorial. What am I doing wrong? No, powerpoint is *not* the correct medium to teach you how to use git. Grr.
Sincerely, an angry programmer.
There's nothing you can do but the AA Serenity Prayer at this point.
Re: (Score:2)
ClearCase also supported the typical 'check your workspace ("view"?) out to a local place on your hard drive, rebase it occasionally, make your changes, and check it in'
Re: (Score:2)
There's not an SCM system made that doesn't suck that I'm aware of. Having said that, I've not used Perforce nor Git. Git has no real integration with my IDEs of choice, and Perforce I only have second hand info on, but former co-workers that have converted to it seem to not be sold on it either. I have considered writing my own, just lack the 8 solid months and desire to do such a thankless task.
I have had the pleasure of using, in no particular order: StarTeam, SVN, CVS, MKS, and ClearCase. SVN was by far
Re: (Score:2)
Self-destructive argumentation, on the other hand, is progressing faster than ever!
Re: (Score:2)
Actually, yes, they do all suck.
Boy, this is fun!
Justin Case (Score:2, Funny)
Re: (Score:2)
git doesn't work well in that sort of scenario.
Where I work, the artists use SVN and the developers use Git.
Re: (Score:2)
That can backfire. I worked at a large company where they did that. The result is that the whole company still uses RCS. Noone can upgrade because that would break the company policy of everyone using the same thing. And they can't all upgrade at the same time because it's a large company and everyone has different deadlines.