[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Attic headaches.
Greg A. Woods
Re: Attic headaches.
Thu, 23 Aug 2001 18:58:51 -0400 (EDT)
[ On Thursday, August 23, 2001 at 22:08:01 (GMT), Kaz Kylheku wrote: ]
> Subject: Re: Attic headaches.
> Nonsense, the CVS code even has explicit support for symlinks.
> When you are committing to a symlink, it will decode the link
> and put the lock into the correct directory. That was fixed in,
> oh I can't remember, 1.10.3 or thereabouts?
I wouldn't trust that code very far, and yes, I have read it. It's not
tested properly in the sanity checks either, especially not for race
conditions. (not that there are any real tests for race conditions! :-)
> >You *WILL* break much more than just the automatic movement of files in
> >and out of the Attic!!!!
> Such as? I haven't had any other problems so far. The only thing to watch
> out for is to clone the file prior to doing cvs remove on it.
locking, for one. "Goodby changes! Too bad, so sad, thanks for playing!"
I don't trust the code that supposedly tries to handle symlinks in the
repository and you definitely should not either. It really should be
ripped out again -- it's far too complex for its own good, and serves
such a poorly defined set of requirements that its very existance is
There's also the very real issue of tagging. From sanity.sh:
# Test 5 reveals a problem with having symlinks in the
# repository. CVS will try to tag both of the files
# separately. After processing one, it will do the same
# operation to the other, which is actually the same file,
# so the tag will already be there. FIXME: do we bother
# changing operations to notice cases like this? This
# strikes me as a difficult problem. -Noel
> I had a number of symlinks which I eventually treated this way; they
> were useful temporarily when reshaping the repository.
You're fooling/deluding yourself.
You MIGHT just possibly be able to get away with symlinks to rename a
module (or MAYBE even a sub-directory), but you'd be much better off to
use proper modules definitions.
Symlinking files though, especially between directories, is a certain
recipe for eventual disaster.
> Suppose you are tracking some outside sources that are arranged
> in one way, but in your repository, the files are moved around a bit.
I use CVS import. Have since CVS-1.4alpha. It's improved a lot
recently w.r.t. supporting file death and resurrection on the vendor
branch, but I've NEVER ever even contemplated trying to use symlinks to
do such a thing! UGH! YUCK! What ever possesed you to try such a
> So what you do is keep a directory tree that has the original shape,
> and then connect things with symlinks. So you can keep doing
> imports of the outside source, and the patches to the moved
> files will go to the right place thanks to the redirection of the
> symlinks. When you no longer need the outside source, you can break the
> links, by duplicating the files.
That's so inside-out, upside-down, and backwards that I wouldn't be
surprised if you've now tied your repository into so many twisty little
knots that you'll never be able to straighten out and do things the
right way without starting over.
> >If symlinks are handy for you then you can handily create them for
> >yourself in your build system!!!!
> That is a little hard when the build system is on an operating system
> that does not support symbolic links.
So make copies and maintain them up-to-date with timestamp (or even file
content) comparison tools (using "make" comes immediately to my mind....)
> Also, symlinks in the working copy hardly provide you with the semantics
> like the above scenario.
You've done the wrong things and gotten yourself into the above scenario
for all the wrong reasons. You'll not be able to manage things properly
until you undo the mess you've created.
Greg A. Woods
+1 416 218-0098 VE3TCP <address@hidden> <address@hidden>
Planix, Inc. <address@hidden>; Secrets of the Weird <address@hidden>