Matthieu Moy <[EMAIL PROTECTED]> writes:
> Robert Widhopf-Fenk <[EMAIL PROTECTED]> writes:
>
>> On Thursday, May 27, 2004 at 17:18:09, Matthieu Moy wrote:
>> [...]
>>> 3) Inspired by 2) : What should we do to reject a patch? The trivial
>>> approach is to merge the patch, revert it manually, and commit,
>>
>> And then the patch will not be in the missing list anymore,
>> how could we omit it from the list with the approaches below?
>
> I'm not an expert, but something like
>
> * merging to the previous patch
>
> * tla sync-tree to include the patchlog of the patch to be rejected
>
> Should do it.
I just had a thought on this. Using the above method, what happens in
the following situation?
* Person A commits a new patch.
* Person B merges with person A, taking their new patch.
* Person C realises that person A's patch breaks something and
rejects it by using sync-tree to skip over it.
So, person C's branch won't contain the broken patch, but A's and B's
will. If someone else tla gets a copy of person A's (or B's) tree, then
merges in the changes from person C, they still end up with the broken
changes.
I guess one solution would be to have the user select any patches they
want to reject, and have Xtla do something like:
While there are patches to merge:
Merge the next patch
If the last patch merged is to be rejected:
Commit with an appropriate merge log
Replay --reverse the last patch
Commit with an appropriate log ("Rejected patch X" or something)
Maybe this is getting a bit outside the scope of what Xtla should be
expected to do, but I thought I'd just throw the idea in.
Cheers,
Mark
--
Mark Triggs
<[EMAIL PROTECTED]>
