John P Cavanaugh <cavanaug@sr.hp.com> writes:
> Hmm. Does this mean that my previous statement on physical conflicts
> vs logical conflicts doesnt hold true??
Actually, I'm going to be not-too-rude-I-hope and back out of this
discussion until we are actually implementing this (as it has no
serious implications toward the current design, that I can see). It's
a complex subject, and we'll have to cover it eventually of course.
-K
> 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