Re: Implicit keep-alive after reintegrate merge
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 19 Jan 2012 11:58:50 +0000 (GMT)
Paul Burba wrote on 2012-01-11:
> A random thought about your patch: The skip/stop logic kicks in when
That could make sense, but your reasoning should apply in general and not just to this patch.
It's not the UI or API semantics we currently have for cherry-picks. Currently, we prune already-merged revisions from a cherry-pick revision range just the same as from a sync merge range. Nowhere in the code do we codify the difference between a cherry-pick and a sync merge, beyond where we parse the command-line arguments. From that point on, we simply pass around a list of revision ranges to consider for merging. The sync-merge UI populates the list with one range; the cherry-pick UI populates the list with one or more ranges.
I'm open to changing that.
> Also, if our detection method isn't foolproof we need a
Agreed in principle, but I intend the detection to be precise.
This is an archived mail posted to the Subversion Dev mailing list.