On Thu, Aug 31, 2000 at 09:33:21AM -0500, Karl Fogel wrote:
> John P Cavanaugh <cavanaug@sr.hp.com> writes:
> > You cant automate detection if a merge is truly pure, but you should
> > be able to detect when it clearly isnt pure, right?? Is it worth
> > having to code to detect false positives??
>
> I think you can't, actually. By allowing users to do the marking, you
> allow them to declare *any* merge pure, including one that involved
> textual conflict resolution.
Hmm. Does this mean that my previous statement on physical conflicts
vs logical conflicts doesnt hold true??
Im trying to understand this, this is what I think I know:
There are 2 types of pure merges (from the viewpoint of just prior
to commit)
1. A pure merge that has no physical conflicts and required no
modification of the files prior to commit
2. A pure merge that had physical conflicts and they were resolved
but did not include any logical conflict resolution
There are also a few types of non-pure merges (from the viewpoint of
just prior to commit)
3. A merge with physical conflicts that were resolved as well as
well as some changes to address logical conflicts
4. A merge with or without physical conflicts (the conflicts were
resolved) but the file also includes some other piece of
code that is irrelevent to the merge
In terms of what we can detect, I think:
Type 1 could be detected programmatically. (ie. using something like
file fingerprints after a successful merge)
Type 2 cant be detected as pure.
Type 3 probably can be detected as non-pure. (ie. were areas of the
file changed that were not part of the delta involved in the
merge)
Type 4 probably can be detected as non-pure. (ie. were areas of the
file changed that were not part of the delta involved in the
merge)
> And this is useful, because they want
> those edits to be considered part of the merge, as though their
> ancestry is the merge source.
Wont subversion *always* show merge ancestries?? Even for non-pure
merges??
Ill also throw a wrinkle in here. Its about our concept of logically
grouped changes. What if a merge happens but doesnt include all
the files as part of the original grouped change, can it still be
a pure merge??
Maybe Ive got csets on the brain, but, would it be useful to introduce
some type of tracking within subversion when logical grouped changes
are separated from each other via merges?? (I dont care on the polarity
here, ie. whether it tracks that they stayed together or whether they
didnt stay together)
-----------------------------------------------------------------------
John Cavanaugh Agilent Technologies
R&D Program Manager 1400 Fountaingrove Pkwy
CAD Data Store Santa Rosa, CA 95403-1799
Email: cavanaug@soco.agilent.com Phone: 707-577-4780
707-577-3948 (Fax)
-----------------------------------------------------------------------
As I grow older, I pay less attention to what men say. I
just watch what they do.
-- Andrew Carnegie
-----------------------------------------------------------------------
Received on Sat Oct 21 14:36:07 2006