Re: Subversion

[Kaz Kylheku]

On Mon, 18 Jul 2005, S I wrote:

> Thank you for your feedback.  I'm definitely vying for CVS myself, however, 
> couple of subversive folks in our company have just heard the hype and 
> hoopla about Subversion and trying to sway my vote too.  I read the user 
> reviews at the bottom of Subversion homepage and they were not good overall. 
>   So I'm very hesitant now, especially that you mention server stability 
> issues with Subversion.  Not to mention Subversion is only @ version 1. If I 
> ever switch, I'd rather wait it out couple of versions.
> 
> Speaking of versions, when is CVS going to give us major features like 
> Clearcase, Perforce, or Subversions: Directory versioning, renaming, etc?

Uhm, have you looked at Meta-CVS? 

Meta-CVS has better support for renaming than Perforce and Subversion.

In Meta-CVS, the state of the local sandbox is handled flawlessly with
respect to file moves, additions and deletions picked up from the
repository. 

The directory structure is treated as a versioned object that is
subject to parallel changes and merging.  This is possible because it's
represented as a structured markup document, rather than a link
structure on disk. Directory structure changes---additions, deletions,
and moves---can give rise to conflicts which are annotated with the
standard conflict markers in the markup document.

If you move ``foo.c'' to ``src/foo.c'', and I rename it to ``bar.c'',
a conflict will happen. One of us will get something like

    <<<<<<<
    "src/foo.c"
    =======
    "bar.c"
    >>>>>>>

which we can edit down to "src/bar.c" for instance. Save the document,
re-run ``mcvs up'' and the resolved directory structure takes effect in
the sandbox. Then commit the change to the repository and it's pushed
to the other sandboxes when they update.

I wrote Meta-CVS because Subversion failed to implement directory
versioning the way I envisioned it ought to work. It didn't scratch the
itch.

I didn't just want a space-efficient representation of directories in
the repository. It's all well and good to represent a directory as a
hierarchical object linked together with pointers, and to generate new
versions of the directory in a way that shares the unchanged pieces of
the old structure. But that's just the data representation. What I
wanted was to be able to treat the directory representation with the
same diff and merge algorithms that work on the file contents.
Give me the algorithms, stupid! I don't care how you store it.
Oh, and make sure my sandbox doesn't screw up under any circumstances.

I didn't want a branch to be a just another directory *within* the
structure; I wanted a branch to be a fork of the directory structure as
a whole in a separate dimension. That is what is intuitive to a CVS
user.

-- 
Meta-CVS: the working replacement for CVS that has been stable since
2002.  It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs