Re: preliminary version control requirements

["Perry E. Metzger" <perry%piermont.com@localhost>]

David Holland <dholland-tech%netbsd.org@localhost> writes:
>  > What's the reason you can't NFS mount in those cases? (I don't
>  > disbelieve you, I just want to understand better.)
>
> Well, for several of them, it's because they're on an unsecured
> university network.

Then use sshfs. It will work just fine for remote mounts, and it works
securely over an unsecured network.

Seems like the "repository is too large" issue is a non-issue.

>  > > Preserving the old version numbers is important because they're
>  > > recorded all over everywhere (PRs, mailing lists, etc.) and losing the
>  > > ability to correlate all those reports with the source tree would be a
>  > > problem.
>  > 
>  > I think there isn't a single VCS that will do that right now.
>
> Monotone will and its conversion script does if asked. Or so I am
> told.

Well, then there is a possible reason to use Monotone.

>  > > > >    - supports rcsids/keyword expansion
>  > > > 
>  > > > Most of them don't per se do this, in that there aren't version
>  > > > numbers for individual files in any modern system so there aren't
>  > > > expandable RCSID equivalents with a file's individual version number.
>  > >
>  > > Why would it have to be a file's individual version number? It just
>  > > has to indicate what stuff a binary file was built with. But we do
>  > > need something that does that.
>  > 
>  > That particular requirement can be met. However, there is an implicit
>  > requirement here that I want to mention is not going to be met.
>
> No, that is not an implicit requirement. It is explicitly (as
> explicitly as is possible without expressly disowning it) not a
> requirement. We need keyword expansion.

We may want it. I think we shouldn't assume we "need" it. It might be
that the benefits of a system that doesn't do keyword expansion
outweigh the issues of not having it. My favorite system (SVN) does
keyword expansion, but I think we should wait until we've seen what
the usability of other systems is like.

So far as I know, there is only one overriding requirement: the
benefits of implementing the new system have to sufficiently exceed
the costs to make it appealing to a majority of the
developers. Everything else is probably negotiable. (Well, there are
*implicit* requirements like "doesn't lose our source tree" but
they're so basic I don't think they're worth mentioning explicitly.)

> We need to preserve the old version numbers for reference.

Well, we always have the old CVS tree. If you're not going to somehow
attach the old version number to the new VCS's version numbers (which
is what you say we don't need to do), then I don't know how you wish
to "preserve" the version numbers.


-- 
Perry E. Metzger                perry%piermont.com@localhost