User: Password:
|
|
Subscribe / Log in / New account

GNOME considers DVCS choices

GNOME considers DVCS choices

Posted Jan 15, 2009 8:30 UTC (Thu) by rrdharan (subscriber, #41452)
Parent article: GNOME considers DVCS choices

Does anyone else find it depressing that Subversion seems to have had a real shelf life of only about
three years?

CVS sucked, but lasted like two decades. Now Subversion has come and is rapidly going away again.

I have no point here and I'm not trying to blame anybody for it (well arguably the SVN developers
simply aimed too low, but whatever). I just find it a little sad to think of all the work that must have
been put into the various projects that switched from CVS to Subversion, and I find myself
wondering if they could've avoided the intermediate step and just stuck with CVS for another few
years until Git/Bzr/Hg showed up.

Of course even if that were true there's no way anyone could've really foreseen how things
unfolded, but still. Just seems like a big waste of time.


(Log in to post comments)

Subversions Relevance

Posted Jan 15, 2009 8:58 UTC (Thu) by alex (subscriber, #1355) [Link]

It had been noted at the time when subversion came out that it was
just a stop gap measure. Essentially Subversion is CVS with some of
it's more glaring rough edges polished. As recently as last year I'd
been arguing that considering SVN as a migration from CVS was a
pointless exercise. In the end I just gave up, mirrored the CVS
repository with a few scripts to import into git and did my
development in git and exported when I needed to.

One thing SVN does have going for it though is the git import tools
for it are more stable than the CVS ones. If a project I'm interested
in hacking is still on SVN and doesn't already have a git repo
associated (most projects usually have at least one git fan already)
then I git-svn import it myself. I'd rather leave it to the core
developer/release teams to decide by themselves what they want to do
than adding my own 2p with a "Please considering migrating to..."
message.

Distributed VCS are the future. Personally I'm a fan of git but there is
scope for many different tools out there. Pretty much all of the open
source options have a good selection of import/export facilities that
allow non-core developers to use whatever their pet favourite DVCS is
to marshal their upstream patches. I'm hopeful that because of this
VC migration will be less of the barrier that it has been between the CVCS
and DVCS generations.

Obviously anyone considering a proprietary non-DVCS system to store
their open or closed source code in these days needs their heads
examining ;-)

Subversions Relevance

Posted Jan 19, 2009 21:22 UTC (Mon) by henning (guest, #13406) [Link]

I don't think that SVN was only a stop gap measure. Its way more better then CVS, its just works and its easy to use. Git its much more powerful, but it makes also easier to shot yourself in the foot. If you want to work with peoples that only develop in their spare time then svn helps to lower the barrier to participate. And If you need to motivate other developers to use a RCS effectivly in their daily routine, then you also don't want to make their life harder then necessary.

And as already noted in the comments, most projects (e.g. inhouse, only a few developers) don't need a DVCS. I don't consider the projects i work ATM as backwards, only because "we still use SVN". IMHO the quality of a project has nothing really to do with the flavour of RCS they use.

SVN 1.0 (released in febr. 2004) was more or less a better CVS. But the svn developers don't stopped there, 1.5.x has e.g. now a much more advanced merge tracking, they improved the repository disk layout, added changeset tagging and much more things.

Shooting in the foot

Posted Jan 20, 2009 8:31 UTC (Tue) by alex (subscriber, #1355) [Link]

GIT is actually fairly safe to use. You have to work quite hard to
exorcise history from the repository although granted most users don't
seem to be aware of the power of the reflog.

My point about ease of access for non core developers basically covers
anyone who wants to do a non trivial patch and not keep a whole diff
hanging around in uncomitted changes in their local copy of an SVN reo.

It's not dead yet

Posted Jan 15, 2009 9:41 UTC (Thu) by niner (subscriber, #26151) [Link]

Tough DVCS are very much on the rise in the FOSS community, there are places where
a centralized VCS is still the preferred way to go, which will likely stay that way. For
example for the in-house development stuff of the company I work for and for sure many
others. We do want to have everything centrally on our backed-up server and it's very
nice to have subversion available for that.

It's not dead yet

Posted Jan 15, 2009 9:49 UTC (Thu) by johill (subscriber, #25196) [Link]

It's not that a DVCS doesn't allow you to have that kind of workflow, if you look at the kernel you'll notice that it almost does have that workflow with many many maintainer trees being hosted on git.kernel.org. But I do agree that it's easier to enforce with svn, since it simply doesn't allow locally committing.

It's not dead yet

Posted Jan 15, 2009 13:50 UTC (Thu) by kpfleming (subscriber, #23250) [Link]

Actually. plenty of developers on Subversion-hosted projects use svk locally to do their work, and then 'push' the results upstream. This is harder to setup and use than if the project used git. In addition, developers are now starting to use git-svn to do the same thing, so the days of the 'master Subversion repo' being the place where everything lives because the tool doesn't allow for any other mode of operation are already gone.

In the future, if the project needs a central 'blessed' repository and wants all work to be done in the open, those needs will have to be met through policy statements and enforcement, because the VCS isn't going to do it.

We have shared git repositories

Posted Jan 15, 2009 15:41 UTC (Thu) by emk (subscriber, #1128) [Link]

At work, we use shared git repositories on a central server. Everybody working on a given project has "push privileges", and they're strongly encouraged to push to master at least once per day.

This has a number of advantages:

1) Git is much easier to back up than Subversion. Correctly backing up Subversion requires an expensive hotcopy step (at least for our ~30GB repository). Git repositories can be backed up either by mirroring, or by straightforward disk backups, thanks to the reflog. (There's a way to recover a Subversion repository backed up in the middle of an operation, but it's messy.)

2) Git+SSH places a lower load on the server than SVN+SSH. At least for big repositories, Git's data structures take far less disk IO to initialize on first launch than Subversion's. This matters to people logging in via SSH.

From a sysadmin's perspective, git is well-behaved. And it supports a very wide variety of workflows, so not every project needs to work like the Linux kernel.

We have shared git repositories

Posted Jan 15, 2009 18:47 UTC (Thu) by drag (subscriber, #31333) [Link]

Ya.. Were I work we have a central Git server that is 'official' then each user hacks on their own little world.

Then when you want to submit your work you clean it up, make sure all the important revisions you've worked on are represented and push it back up to the central git server. That way you get the benefits of showing all the major stages you've gone through, and get it represented in the history on the main git server, in your own work while avoiding forcing users through the dozens of commits a hour you do while hacking away.

It's very nice to do a commit every time you close out a file or make a risky edit to something. The more you use it the more useful it gets.

GNOME considers DVCS choices

Posted Jan 15, 2009 14:50 UTC (Thu) by iabervon (subscriber, #722) [Link]

I think that a large portion of the effort of converting from CVS to SVN was in figuring out what the projects actual history was (figuring out when files were moved within the repository and turning that into a history where the file was in the original location until it moved; figuring out which modifications were in the same commit, etc). SVN is able to represent project history in a clear way, and people are less likely to do strange things, so moving to another system is not so difficult, and the work of getting there from CVS would have had to get done anyway.

The tools for importing to git from SVN, for example, are pretty straightforward. The tools for importing to git from CVS are complex and do a lot of guessing about things that git needs to know that CVS doesn't preserve.

GNOME considers DVCS choices

Posted Jan 16, 2009 0:57 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Bear in mind that when SVN came out, there were already more technologically advanced options available. And SVN was still sorely needed. SVN's one great advantage over all of them (and Git): it's easy to migrate to it from CVS. The biggest cost of migration, remember, is the effort of users and administrators to learn the new thing. I have personally persuaded many reluctant people to move from CVS to SVN, using assurances like, "you'll use all the same commands: svn checkout, svn commit, svn diff, ..." I could never persuade these people to migrate to Git.

I spent an hour trying to understand Git recently, and ultimately had to put it off for some other time, because it's too unlike something I know and the documentation is too poor.

So while Git is going to do what Subversion's original competitors couldn't because Linus forced huge numbers of people to get familiar with it, I expect Subversion has a long life ahead of it.

GNOME considers DVCS choices

Posted Jan 16, 2009 15:35 UTC (Fri) by kevinbsmith (guest, #4778) [Link]

I'm not sure how long svn's life will be, but I agree that it was a useful transition. Moving our projects from cvs to svn was trivial, and we waited long enough for the end-user tools to have the features we needed. Basically, there was no reason to stick with cvs, at a time when it was not yet clear which dvcs we should choose. For many projects, it's still not clear which dvcs would be the best for that project.

On a personal project, I am now using bzr as the front end to an svn repository. Very cool. Yet another incremental step. I have been a strong dvcs advocate for a few years now, but a sudden complete switch is not always possible or smart.

GNOME considers DVCS choices

Posted Jan 20, 2009 13:30 UTC (Tue) by whacker (guest, #55546) [Link]

I have helped companies migrate from VSS to Svn.

Of all the features that I needed to demonstrate, the one thing the users (read: managers) wanted most was: restriction of commit access to specific folders in the same project! There was this strange fear that people would 'accidentally' commit to parts of the code they were not supposed to!

No amount of me convincing them that neither locking nor permissions were really meaningful in a version controlled system made any headway.

GNOME considers DVCS choices

Posted Jan 20, 2009 21:27 UTC (Tue) by jlokier (guest, #52227) [Link]

How are permissions not meaningful?

Sure, everyone's work is in the version history *somewhere*.

But it's easy to slip in a change which persists without anyone noticing, if there are hundreds or thousands of commits a week.

Changes to some code should be reviewed by people closely affiliated with that code, and permissions are helpful for ensuring that review does happen.

Permissions aren't the only way to ensure a particular workflow. Maybe triggers could flag when changes are made be people who aren't in a pre-approved list for a particular subsystem. Allowing changes and sorting out the conflicts afterwards are more in keeping with modern VCS methodology.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds