text: 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:
  >
  >
  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.
  --.