Re: Reality check

On Tue, Dec 18, 2007 at 07:05:27AM -0600, Ben Collins-Sussman wrote:
> On Dec 17, 2007 9:37 PM, Roy Franz <roy.lists@gmail.com> wrote:
>
> > I personally think that some of these basic usability issues are much
> > more important than offline operation, etc.
>
> The only reason you can answer the question "which tags contain this
> file?" so easily in CVS is because tags are based on labeling files.
> The underlying RCS file has the list of tag-labels right there, ready
> to go. The tradeoff, of course, is that creating tags becomes an O(N)
> operation -- I've seen companies sit and wait for *hours* to make a
> tag on big trees in CVS or Clearcase.

I've been doing this myself and it really sucks!

I maintain a set of changes against the FreeBSD source tree to
implement support for wake on lan. I've been doing so in a copy
of their CVS repository. They have hacked cvs to allow maintaining
local branches in a repo copied with cvsup. But maintaining my
changes on two branches (for FreeBSD 6.x and 7.x) involves much tagging
and merging which takes a long time in CVS. A single tag alone takes about
30 minutes on a tree the size of the FreeBSD source tree, even though
the repo sits on local disk! So most of the time I can spare to work
on this involves waiting for CVS.

I'm still looking for alternatives, but have not yet found a solution
that does not involve a vendor branch. I want incremental native cvs imports
instead, cvs2svn doesn't seem to support this. It seems there is no tool
that supports icremental imports and is at the same time actually able to
import a single branch from the FreeBSD CVS tree. Neither git-svnimport
nor "mtn cvs_import" manage that without crashing. I'll probably have
to look into the non-free perforce next :-/

> You might want to read this, as it directly talks about your problem:
>
> http://svn.collab.net/repos/svn/trunk/notes/schema-tradeoffs.txt

Interesting hint, I'll look into that some time.

I wonder though if there really isn't a way to get both O(1) tagging
and O(1) "file @rev" -> "tag" lookups in the current design.

With "copied-to" info in the repository (instead of only "copied-from"
info) we'd get a bit quicker at answering "file @rev" -> "tag" mappings,
but I'm not entirely sure if this is a clean solution.

-- 
Stefan Sperling <stsp@elego.de>                 Software Developer
elego Software Solutions GmbH                            HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12        Tel:  +49 30 23 45 86 96 
13355 Berlin                              Fax:  +49 30 23 45 86 95
http://www.elego.de                 Geschaeftsfuehrer: Olaf Wagner