Re: Repository directories and symlinks

[Kaz Kylheku]

In article <address@hidden>, Alleman, Lowell wrote:
>
>I want to reorganize the directory structure of my cvs repository, but there
>are still a number of sandboxes lying around and a couple of scripts which
>rely on certain files being at certain locations within the repository (It's
>not ideal, but it's what I have to work with.).  I would like to move the
>directories to where I want them, and then make symlinks connecting the old
>and new locations.
>
>Yes, I've tried doing this with the modules file, but it just isn't flexible
>enough.  I either can't use the name I want or position the module under
>another module, or I end up with superfluous modules names.....  If I'm
>missing something here, let me know.
>
>
>Symlinking directories within the repository:
>
>1.  Will it work?

Sort of.

>2.  Will I loose data?

Probably not, but you could screw up your ability to go back to old
releases if you don't know what you are doing or aren't careful.

>3.  What other problems can I expect?

- When files move in or out of Attic directories, symlinks break. This
happens when files are removed on the main trunk, or added on a branch
and then commited to the main trunk.

- When a file is removed (via cvs remove), then every symlink pointing
to it appears removed; it's necessary to manually break the symlink
before doing a cvs remove. Breaking the link meaning that the object
to be removed is an actual object, and not a link, and has no links
pointing at it.

- Older versions of CVS didn't handle symlinks right; they did not
chase the link and acquire locks in the right places.  this was
fixed around 1.10.3. 

Because of these problems, symlinks become a liability. Users cannot
manage these symlinks themselves, only some person in charge of the
repository. You can't have people mucking around in the repository
to get their jobs done, it's just not sound CM. If you do have some links,
and other people don't realy know about them, and you get run over by
a bus, the above problems will eventually bite people who might lack
the CVS expertise to know what to do.

>4.  Is there a better way?

<plug>

I have a client side solution called Meta-CVS.

http://users.footprints.net/~kaz/mcvs.html 

This is alpha software, that currently runs only on GNU/Linux.  Sane,
robust versioning of the directory structure (and that means parallel
changes with merging and conflict resolution).  Plus sane file adds
and removes. No changes to CVS are required, and nothing needs to be
installed on the server side. On the downside, there is the current platform
restriction; moreover, it can't use existing modules without conversion,
for which I haven't yet written the tool. Some tools designed to work
with CVS won't work with Meta-CVS, such as probably most GUI front
ends like WinCVS which peek at the CVS subdirectories that don't exist
under Meta-CVS.  Caveats aside, I'm extremely happy with it and I'm using
it already. You might not be able to use it now, but at least you have
one possible light at the end of the tunnel. 

</plug>