You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@galois.collab.net> on 2000/08/29 23:37:01 UTC
doing Perforce-style "pure" integrations
Without going into too much detail, I just want to point out that
Subversion should support the concept of the "pure integration", like
Perforce:
http://www.perforce.com/perforce/branch.html
(search for "pure" in that page)
For example, if you merge branch B into a locally-unmodified trunk,
but end up doing some conflict resolution before you commit that
trunk, you want to be able to tell Subversion that it's still a pure
merge. Meaning that when you commit, the ancestors added to the new
version N's ancestor set should be exactly those obtained from the
merge from B -- the stuff you did for conflict resolution doesn't
count. That way, if you later have to merge back from the trunk to B,
the change N will will not be included in the merge, because B knows
it already has those changes, even though textually they might not be
exactly what B already has.
Well, that's a bit terse, but between that and the paper you should
get the idea.
Note that it's not an automatic thing -- Subversion can't decide for
the user whether or not to mark a commit as being from a pure merge;
some merges are and some aren't. The user has to consciously flag it
as pure.
-K
Re: doing Perforce-style "pure" integrations
Posted by Karl Fogel <kf...@galois.collab.net>.
John P Cavanaugh <ca...@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
> -----------------------------------------------------------------------
Re: doing Perforce-style "pure" integrations
Posted by John P Cavanaugh <ca...@sr.hp.com>.
On Thu, Aug 31, 2000 at 09:33:21AM -0500, Karl Fogel wrote:
> John P Cavanaugh <ca...@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
-----------------------------------------------------------------------
Re: doing Perforce-style "pure" integrations
Posted by Karl Fogel <kf...@galois.collab.net>.
John P Cavanaugh <ca...@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. And this is useful, because they want
those edits to be considered part of the merge, as though their
ancestry is the merge source.
Re: doing Perforce-style "pure" integrations
Posted by John P Cavanaugh <ca...@sr.hp.com>.
On Tue, Aug 29, 2000 at 06:37:01PM -0500, Karl Fogel wrote:
> Without going into too much detail, I just want to point out that
> Subversion should support the concept of the "pure integration", like
> Perforce:
>
> http://www.perforce.com/perforce/branch.html
> (search for "pure" in that page)
>
> For example, if you merge branch B into a locally-unmodified trunk,
> but end up doing some conflict resolution before you commit that
> trunk, you want to be able to tell Subversion that it's still a pure
> merge. Meaning that when you commit, the ancestors added to the new
> version N's ancestor set should be exactly those obtained from the
> merge from B -- the stuff you did for conflict resolution doesn't
> count. That way, if you later have to merge back from the trunk to B,
> the change N will will not be included in the merge, because B knows
> it already has those changes, even though textually they might not be
> exactly what B already has.
Its probably apparent to all, but I thought it might be work
highlighting that this is for *physical* conflicts resulting from a
merge only. Not for logical conflicts (ie. semantic changes etc) that
popped up after the merge.
> Note that it's not an automatic thing -- Subversion can't decide for
> the user whether or not to mark a commit as being from a pure merge;
> some merges are and some aren't. The user has to consciously flag it
> as pure.
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??
-----------------------------------------------------------------------
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
-----------------------------------------------------------------------