Mark Triggs <[EMAIL PROTECTED]> writes:
>>>> 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.
* Person A and/or B merges with C ...
The problem is here. Not sure about what exactly will happen, but
I suppose the "merger" (A or B) will get a conflict here.
> 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)
Yes, I like this approach.
I think we must distinguish two situations:
* "Centralo-distributed" development: One committer on a master
archive, and people submitting "merge requests" to the main committer
(like Tom is doing for tla's development). In this case, the approach
"merge to the last but one patch and sync-tree" works because people
will never merge from someone other than the main comitter.
* "Completely distributed" development: Like the approach of xtla.
People merge from each other regularly, there's no "main" archive. In
that situation, all the patches from all the main contributors should
be accepted first, and possibly _reverted_ afterwards. In this case,
your approach is, I think, the right one.
> 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.
I don't think so. This is not the nb 1 priority, but I'd like to see
that in Xtla one day.
--
Matthieu
