Thanks for the clarification, Kamesh.
At one time or another, I've heard people suggest that, as part of
this merge-tracking work, we ought to have two subcommands:
- patch: the old "merge", without merge info
- merge: the new one, with merge info
I guess that idea died. Too bad: this is a good illustration of the
problem it was trying to solve. If you're thinking of "merge" as
being "the thing with all this merge info history," then this case
you call "self reversal" really isn't a merge at all; the "patch"
command would be fine.
On Oct 21, 2007, at 12:11 AM, Kamesh Jayachandran wrote:
> >There is only one attempted reverse-merge in my example, and indeed
> >that one doesn't do anything so far as I can see, so in some sense
> >there are zero. I don't understand, then, why you end up asking
> >questions about *repeat* reverse merges.
> As I mentioned in one of my email,
> * We don't record reverse merges *explicitly*, i.e no recording of
> mergeinfo /src:-17
> Please mean 'Avoid repeat reverse merge' === 'Allow reverse merges
> only if there exists a corresponding forward merge' to be more
> clear in our earlier discussions
> I agree it is annoying, We fixed this, by handing 'self
> reversals'(as your example) as a special case.
> P.S self reversals = reverse merge from same source as that of the
> target. After all rX committed on path /target implicitly
> equivalent 'merge of rX changeset from /target to /target'
> >Perhaps your thought is, more or less, "we have to do something or
> >other about repeat reverse merges, so what policy is acceptable on
> I don't think it is the policy change rather a way it should have
> been originally done as a part of 'avoid repeat reverse merge'.
> With regards
> Kamesh Jayachandran
Chief Technology Officer
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
Received on Mon Oct 22 08:28:48 2007