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

GNOME considers DVCS choices

GNOME considers DVCS choices

Posted Jan 16, 2009 15:35 UTC (Fri) by kevinbsmith (guest, #4778)
In reply to: GNOME considers DVCS choices by giraffedata
Parent article: GNOME considers DVCS choices

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.


(Log in to post comments)

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