[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: planning for resurrection
From: |
Hendrik Boom |
Subject: |
[Monotone-devel] Re: planning for resurrection |
Date: |
Thu, 3 Jul 2008 01:02:18 +0000 (UTC) |
User-agent: |
Pan/0.132 (Waxed in Black) |
On Wed, 02 Jul 2008 09:54:00 -0400, hendrik wrote:
> In another thread, I recently said,
>
>> Now there are some large files that were build as part of normal
>> development, but were abandoned because of sustem limitations long ago.
>> While I don't expect to develop in these directions myself, others
>> might well want to.
>
>> If I check them in, and then delete them, they will be part of the
>> historical record, but it will be impossible to resurrect them later,
>> because of die die die merge. So this is perhaps not the way to go.
>
>> But if I don't delete them they will remain in the head of the active
>> project whether they are used or not. This is also undesirable.
>
>> Is there some clever way around this? Would branches help?
>
> Reading some more in the mailing list, I find that resurrection is a
> sore point. But since it's unlikely that anyone will be doing anything
> with the abandoned files until someone decides to resurrect them, it
> would seem to suffice to check in a new file sometime in the future that
> happens to be the same as the old file. There won't be revisions from
> the graves coming back to haunt us later -- just revisions on the
> resurrected file.
>
> So I can, for now, just check the ancient relics in and delete them.
>
> Does anyone see problems with this approach? Or is there a better one?
>
> -- hendrik
I guess there's the technique of checking the abandonware into a
different branch, and just leaving it there. Some of it could be other
versions of main-branch files, but they have diverged so much that they
are effectively unmergeable at this point.
Would this work? Or does it have unforeseen side effects?
-- hendrik