[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: doing Perforce-style "pure" integrations

From: John P Cavanaugh <cavanaug_at_sr.hp.com>
Date: 2000-08-31 20:11:12 CEST

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

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

> 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

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.