[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 23:33:25 -0400 (EDT)
[ On Friday, August 24, 2001 at 00:23:38 (GMT), Kaz Kylheku wrote: ]
> Subject: Re: Attic headaches.
> A twisted mind, clearly. Handling death and resurrection isn't good enough.
> If the external project has a file called foo/bar.c but in your version
> it's moved to xyzzy/bar.c, you still want the vendor patches that are done to
> foo/bar.c to continue to be applied to xyzzy/bar.c. So, in goes the symlink,
> creating a handy little ``wormhole'' for the patches to be funneled
> to the new home. :)
Your twisted mind has failed to understand the issues of tracking change
history across a group of related files, or maybe has reasoned it away.
You have effectively eliminated much of that history by hiding the death
and resurrection of files behind your twisted little symlinks.
> None of the few remaining symlinks are related to this technique at all,
> they are just very rare instances of braindamaged file sharing. I'll
> get rid of them in due time.
I must say I'm flatly stunned that anyone would get themselves into such
a brain-damaged situation in the first place! Two wrongs do not a make
You've as much used the wrong tool (i.e. symlinks) for the job as anyone
trying to hammer in finely machined wood screws is doing....
> What disturbs me somewhat that you don't trust the symlink handling code
> which places a lock in the right place.
No, I certainly do not trust the symlink handling code. That code is
rather complex, and was basically bolted onto the side of the directory
hierarchy traversal code as an afterthought, and in places is clearly in
contention with the fundamental operation of CVS.
> So as you can see, I did not enter into the use of symlinks with my
> eyes closed. There was reasonable preparation, testing and planning.
> The only issue I ran into with symlinks was the Attic move.
I'm still stunned. You seem like you've got a deep enough understanding
of the issues to know flat out that you should not have done what you
did, and yet you did it anyway. You seem like you should have known how
to come up with a proper scheme of managing this scenario yet you went
ahead and did something that you seem to agree was a bad thing!
> I don't like symlinks in the repository, but they have been a kind
> of necessary evil.
I'm sorry, but that's just plain flat out not true at all, ever!
Symlinks are NEVER necessary. (though they certainly are evil,
especially in the repository! :-)
They are a convenience only, and you have used them to conveniently mask
important aspects of the hierarchy of your projects from CVS' view!
I suppose the fact that CVS has half-baked support for symlinks in the
repo should be even more disturbing to me. Last time I looked at the
code though I only did so long enough to assure myself that it wouldn't
be in the execution path so long as I never created any symlinks in the
repo. If I'd had more time and energy at the time I would have ripped
it out again on sight (though that would have no doubt taken me even
more directly down a road I'm not quite ready to walk).
> Anything that requires manual intervention in the
> repository is a bad thing because the general user population cannot
> (and must not be allowed to) maintain it. So they are not part of some
> long-term nefarious plan to twist the repository into knots and loops
> that can never be unravelled again!
Not only that but it destroys/hides/undoes the history of change --
i.e. masks the very reason why you're supposedly using a version control
tool in the first place!
Some people complain about the modules file not being well enough
integrated into the tagging system so that the right version of the
modules file can be used to more correctly retrieve previous revisions,
branches and such. In the mean time here you are mucking about in the
repository creating and breaking symlinks with apparent complete
oblivion to the fact that you're probably destroying your ability to
re-create previous releases, and certainly destroying your ability to
re-create historical snapshots by date.
Greg A. Woods
+1 416 218-0098 VE3TCP <address@hidden> <address@hidden>
Planix, Inc. <address@hidden>; Secrets of the Weird <address@hidden>