Re: Notes from the version control BOF at the summit

[Ian Lance Taylor <ian at wasabisystems dot com>]

Walter Landry <wlandry@ucsd.edu> writes:

> Ian Lance Taylor wrote:
> > * Must preserve existing history
> >     We can not discard our existing CVS revision information.  It was
> >     bad enough losing the older RCS information (it is available in
> >     the old-gcc directory in the CVS repository on gcc.gnu.org, but
> >     that is inconvenient).
> 
> How good must the translation be?

I would say that it must be good enough to see old revision history
and to support the ability to check out old releases.  I think we
would need revision history for old branches, but I'm not sure we
would need the ability to continue development on those branches
precisely--it might be OK to start again with branches.


> > * The tool must be around for a while, and continue to be supported
> >     We don't want to have to change again, at least not for a while.
> 
> Define "a while".  Has svk been around "a while"?

There is no precise definition, I'm afraid.  I expect that the gcc
community as a whole, and the steering committee in particular, would
have to believe that the version control system was going to be around
in the future.


> > * Ability to work offline
> >     For example, the ability to do diffs and examine logs while not
> >     connected to the Internet.  Some systems support doing a commit
> >     while not connected; more on this below.
> 
> Is this meant to exclude centralized version control systems?

No.  This is not a requirement; it is a desired feature.  Doing diffs
and logs offline is more important than the ability to do commits
offline.


> > * Run on Unix, Windows, Mac
> >     CVS does this already, and we need it.
> 
> Is Cygwin acceptable, or must it be a native port?

I think cygwin would be acceptable, though it would have to have
reasonable performance.


> > * Language support and character set conversion
> >     A simple case is appropriate line endings for text files.
> 
> Are you sure you want this?  Certainly being able to support
> multilingual filenames and data is good.  But to go beyond that and
> start transcoding things in the version control system seems fraught
> with peril.

Somebody else will have to address this--I didn't entirely understand
the suggestion.


> Finally, is it important to retain file permissions?  Is it important
> to version directories?  Do you need any kind of integrity checks or
> patch signing?

For gcc, I would say that it is not important to retain file
permissions, beyond the distinction between executable and
non-executable.

I'm not really sure what it means to version a directory; if it means
that a directory can be on some branches but not others, then I think
that would definitely be a nice feature.

Integrity checks and patch signing would be nice bonuses, but they are
not required.  gcc operates under social conventions, and generally
relies on trust within the community, and the ability to expel people
from the community (although I don't think that has ever happened).
Adding technical measures like patch signing would not replace the
need for trust.

Ian