Re: CVS should die

twp(at)castle(dot)fastmail(dot)fm (Travis P) wrote in message news:<F54111AA-35EB-11D9-B14F-003065F9DAF8(at)castle(dot)fastmail(dot)fm>...
> > "Misinforming the user on rename with local changes"
> > dev(at)subversion(dot)tigris(dot)org
> > news://news.gmane.org:119/419379F3(dot)5070302(at)ftml(dot)net
>
> Might be easier to read with a browser here:
> http://svn.haxx.se/dev/archive-2004-11/index.shtml
>
> Yes, looks like it could be a potential problem/inconvenience if a file
> is both moved and altered simultaneously.

You guys should check out the software that I developed called
Meta-CVS.

It creates a version control system that has directory structure
versioning, over top of the file versioning semantics provided by CVS.

Meta-CVS does not have problems with these corner cases, by design.

> I see the risk of problems as similar to those that if two people edit
> the same section of the same file at the same time, complicated
> conflicts could emerge.

In Meta-CVS, conflicts in the directory structure are exactly like
these conflicts, because the directory structure is marked up as a
straightforward text document.

When conflicts occur, you can read that document and it's obvious that
one user wanted to rename foo.c to src/foo.c, whereas another one
wanted to rename it to foobar.c.

Meta-CVS completely separates the directory structure from the files,
in the classic way: just like Unix file systems, and network file
systems like NFS and others. A file is known by an 128 bit identifier
encoded as text in hexadecimal.

So for example, even picking up a deletion to a locally modified file
is safe.

Suppose you have been editing a document foo.txt, do a ``mcvs up'' and
it's deleted. Your changes are still safe and can be committed. All
that happened was that your foo.txt was unlinked from the directory
structure. The real object, still exists, and has all your changes. It
can be committed to CVS. Independently of that action, you can
re-introduce your object into the directory structure: just change the
markup document (a file called MAP in the MCVS directory at the root
of your project) and then run ``mcvs up''. Meta-CVS will notice the
change, and link the file into the appropriate place, as requested by
the new markup. You can commit that markup change, and the file will
reappear in people's sandboxes when they pick it up.

> It is too bad the Subversion design didn't anticipate this such that
> it's not a problem at all, but in many environments, it may not be much
> of an issue.

Fortunately, I anticipated the problem before I laid down the first
line of code.