Re: Attic headaches.

[Kaz Kylheku]

In article <address@hidden>, Greg A. Woods wrote:
>[ 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.

Nope; no history was ever lost. It's called ``copy on write''. You simply
have two (or more) files in separate places that happen to share the
same representation. And then one day they no longer do that. But
their histories, up to that point, are identical and remain that way.

So in this example, foo/bar.c and xyzzy/bar.c would be the same object
for revisions 1.1 through 1.10, say. At that point I decide that
they won't be virtual copies of the same object any more, so I
ensure they are both distinct, identical files rather than one being
a link to the other. After that point, a change committed to one 
no longer appears in the other.  This is useful if I want to make one of
them dead, but keep one of them living.

But their history from 1.1 through 1.10 remains identical forever,
even though they diverge now.  So I can revert to an exact old release,
and the ``evil'' symlink is gone. See? No history is lost.

Of course, this has to be carefully managed. If you were to do something
stupid, like cvs remove one of them while they are still linked, the
other will be cvs removed. That's what you get when there isn't complete
support for symlinks in the tool.

>> 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
>a right!

But I'm not in any ``situation''!  I had a bunch of symlinks, most
of which are gone.

Look, you try incrementally migrating a whole bunch of people and code
from a braindamaged version control system to CVS, where you have files
linked together under the old system, and you want to keep up with
bugfix patches from there for a while, at the same time as cleaning it
up to do it right under CVS.

I pulled it off with the help of a very carefully staged plan involving
some temporary symlinks, under which all the constraints for doing
it correctly were ensured, so that no file's history was damaged,
and no merge had to be done by hand.