Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > On Mon, 19 Dec 2005, Russ Allbery wrote:
>> This may not be the most popular opinion, particularly among fans of >> distributed VCSes (and I do understand the merits), but wrapping your >> mind around the distributed model isn't easy. I can explain to >> sysadmins who have never used a VCS before but who have compiled >> software and can work on Debian packages how to use Subversion, but >> explaining bzr feels rather intimidating. > " You have a central entity, be it a person (the project leader for > example) or a bot, which has write access to the main repository. > Everyone sends commits (working changesets) to this person/bot, for them > to get merged to the main repository. You just lost the people that I'm talking about. I can explain a changeset, but merges are deep black magic that are extremely difficult to understand except at a highly abstract level, and when using a distributed VCS, they have to deal with merges all the time. In a typical Debian package maintained in Subversion, they will *never* have to merge except to import new upstream source, and if using something like dpatch they don't even have to do it then and can appeal for help to one of the experts on the team if the patches require fiddling to update. And for many packages that don't require Debian-specific modifications, you don't have to deal with either. In Subversion, merges are a problem for large projects with lots of people committing simultaneously. This is not the typical case for a Debian package. > Everyone has a local read-only copy of the main repository that they can > use even while offline (which they sync to the main repository every now > and then). Everyone has a local read-write repository that they use for > ongoing work, even while offline. It is this work that, when deemed > ready, is sent as a changeset for inclusion in the main repository. " Speaking from direct personal experience, nothing confuses people more about VCSs than having multiple repositories. This is another huge stumbling block. People understand a central server and a single local checkout that they make modifications in; once you add another local repository, they immediately get very confused as to what goes where and what order operations are supposed to be done in. Yes, all of this stuff can and should be explained to people who are doing serious software development, as understanding the distributed model is quite valuable. But for people who are just casual helpers with Debian packages that they're interested in, this stuff is very complex and intimidating. Part of my day job is maintaining VCS systems for a group of system administrators without a lot of software development experience, and explaining CVS with a single shared central checkout (i.e., CVS in RCS mode) is almost as much complexity as they want to handle on a regular basis for something that isn't a core day-to-day part of their job. > What IS difficult about it? It is exactly how the Linux kernel is > managed, only they have various layers of "project leaders" and no bots. Most people aren't going to be able to contribute to the Linux kernel, or would even try beyond maybe sending a patch. > Nobody in the system administrator, development or operation areas where > I work would have too much difficulty grasping the basic idea, and it > wouldn't take much time to explain the specifics (repository mirrors, > etc). > Whatever the issues of svn versus bzr are, difficulty of grasping the > bzr way of doing things shouldn't be one of them. Well, my personal experience says that you have an unusually VCS-friendly set of people to work with, and that this is indeed a problem. But I suppose I'm arguing from anecdote. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
