On Wed, 2004-11-17 at 11:16 -0600, Ben Collins-Sussman wrote:
> My sources tell me that Mono is also being viewed as a guinea pig for a
> possible switchover of the entire GNOME project.
I'm not sure this is true. (I don't remember seeing any serious
discussion of GNOME svn migration anywhere.) However, it is true that if
GNOME did switch, it would have many of the same issues as mono had.
(Except the CRLF ones).
> I'm told that the main attraction for Mono folks was offline diffing
> and reverting, and possibly interested in rename support.
Move/rename support is big. For instance, we've been unhappy with the
organizational split between the "mono" (runtime) and "mcs" (compiler
and class libraries) modules for a while, and this is much easier to fix
in svn than it would be in cvs.
> Apparently Mono has been fighting EOL-style problems for years in CVS.
> They tell me that every once in a while, a win32 developer will
> accidentally check in CRLF line endings.
Not quite accurate. The project was initially bootstrapped via the C#
compiler on Windows, so all of the early development was done on
Windows, so all the original files had CRLF endings. Since both Emacs
and Vim on Unix deal fine with either CRLF or LF, it was never that huge
a deal to anyone. However, there are occasionally problems, and more
recently, some files ended up with a mix of LF and CRLF endings somehow
(probably someone using a non-CRLF-aware editor).
> I suggested that they fix the problem by just correcting the chunks
> and committing; but they don't want to do this, because it will "mess
> up the ability to annotate." Apparently the idea of running 'svn
> blame' twice instead of once is far, far worse than seeing spurious
Well, no, it's just that it seemed like if we were clever enough, we
could get BOTH uniform line endings AND consistent blamage, and we
didn't want to give up either unless we had to. :)
> *** Annotation dependency
> *** Cultures at different scales
These sections are pretty much right on. Another important part of this
is that the developers are geographically dispersed, so even in parts of
the project where there is just a small group working on some
subproject, you often can't just "ask your officemates" (even over irc)
because of timezone differences.
> *** The Changelog file
> I suspect that this one developer won't be happy until he
> starts using arch or svk (he's definitely hinted at wanting
> distributed repositories).
Yes, there are definitely a few people on the team who think we should
have switched to arch instead.
> So, no action item here -- just a mental note for future projects.
> You may run into resistance trying to persuade them to drop
> 'Changelog'... especially really huge projects.
Yeah, exactly. This isn't really a cvs vs svn thing at all, it's just a
project culture thing. (There are huge projects that use CVS and don't
use ChangeLogs. NetBSD, for instance, has cvs history going back to
1993, and gets by fine with just "cvs log".)
> 1. No project should ever jump into a new version control system
> without experimenting with it first, or assessing the general
> impact it will have on development policies. Switching VC systems
> is never "just" about learning the syntax of a new program -- it
> always involves re-evaluating and re-creating all of your
> project's procedures. Do the research, and assess the impact
> before jumping off the cliff.
> 2. For Mono in particular, it's not clear to me that there's been any
> net benefit in switching to Subversion.
Well, see, I think our perspective was more along the lines of "if we
switch to svn, we don't have to learn anything new, and we get moves and
renames for free!". Most likely, as we continue to use svn, we'll slowly
adapt our work style to the new functionality, but changing things right
away was an explicit non-goal.
I think a lot of other projects that are looking at subversion have a
similar POV. Some might care more about branching or WebDAV support or
something else, but in general, most of the discussion of svn I've seen
is along the lines of "it's just like CVS, except you also get foo".
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Nov 17 23:01:57 2004