Re: merge tracking use cases

[Daniel Rall <dl...@collab.net>]

On Fri, 30 Nov 2007, Mark Phippard wrote:

> On Nov 30, 2007 5:59 PM, David Glasser <gl...@davidglasser.net> wrote:
> > So, we have this merge tracking use cases/requirements doc:
> >
> > http://subversion.tigris.org/merge-tracking/requirements.html
> >
> > Which of these does current trunk (or "current trunk plus easy changes
> > that we know how to do") support?

Ignoring some bugs in what we do have, what we don't support fully
includes:

- Merging
  - The parts of Repeated Merge dealing with reflected/cyclic merging
    (issues #2897 and #2837)
  - Block/Unblock Changeset
  - Parts of "Handle Renames" (some of which cmpilato has in progress)
  - Properties

- Miscellaneous
  - Authorization (I'm not sure about this one)

> > Note that I don't see anything there that reminds me of #2897,  (Am I
> > missing something?)
> 
> I was updating Jack Repenning on all of this to get his take.  He said
> that #2897 is the most common use case.  It is what everyone that uses
> ClearCase UCM does (in fact it is officially called the "Standard Use
> Model") and if Subversion does not have that feature then it does not
> have merge tracking.
> 
> I cannot really disagree.  I raised this back in June and I've raised
> it several times since then.  It is hard to argue that we have
> advanced the bar if a user cannot merge a branch back to trunk.

Issue #2897 is a core part of the Repeated Merge use case.  Issue
#2837 is coupled (almost the same), but the plan was to defer that
part for post-1.5.

Re: merge tracking use cases

[Daniel Rall <dl...@collab.net>]

On Fri, 30 Nov 2007, Justin Erenkrantz wrote:

> On Nov 30, 2007 4:02 PM, Daniel Rall <dl...@collab.net> wrote:
> > Ignoring some bugs in what we do have, what we don't support fully
> > includes:
> >
> > - Merging
> ...
> >   - Block/Unblock Changeset
> 
> Not that I have much time right now to invest in this, but this lack
> of block is going to make merge tracking very very annoying - probably
> so much that I wouldn't even use merge tracking.
> 
> Perhaps the easy way out is to just have 'svn block -c xxxx' do a
> record-only merge?
 
That's not a bad idea, actually.  We provide a formalized command, document
the fact that you should record which values from svn:mergeinfo are blocked
for auditing and later migration, and fix the command in a subsequent
release.  Given the amount of call we've had for this function, I can see
delivering *something* now as valuable even if the implementation is somewhat
questionable.

> But, if a rev constantly appears in the avail list, that's gonna be
> downright annoying - probably so much so that I'd stick with
> svnmerge.py.  The galling point is that I don't think I'm the only one
> who uses block or expects it to be there.
 
Justin, you are most definitely not alone here.  I get constant requests
for this feature.

The main reason for its deferral is the existence of the work-around of
using 'svn merge --record-only' with a separate "blocked" list; if these
other buggy or to-be-implemented features had work-arounds, I'd definitely
see this as prioritized higher.

If we were going to implement it like the suggested work-around, adding a
svn:blocked-mergeinfo property which contained references to values also
present in the svn:mergeinfo property pretty simple at face value, but when
you factor in elision, and the need to synchronized adjustment of both
property values, will take longer than one might expect to implement.

> (I frankly care more about block than I do about bi-directional
> merges.)  -- justin
-- 

Daniel Rall

Re: merge tracking use cases

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Nov 30, 2007 4:02 PM, Daniel Rall <dl...@collab.net> wrote:
> Ignoring some bugs in what we do have, what we don't support fully
> includes:
>
> - Merging
...
>   - Block/Unblock Changeset

Not that I have much time right now to invest in this, but this lack
of block is going to make merge tracking very very annoying - probably
so much that I wouldn't even use merge tracking.

Perhaps the easy way out is to just have 'svn block -c xxxx' do a
record-only merge?

But, if a rev constantly appears in the avail list, that's gonna be
downright annoying - probably so much so that I'd stick with
svnmerge.py.  The galling point is that I don't think I'm the only one
who uses block or expects it to be there.

(I frankly care more about block than I do about bi-directional
merges.)  -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: merge tracking use cases

[Blair Zajac <bl...@orcaware.com>]

Daniel Rall wrote:
> On Fri, 30 Nov 2007, Mark Phippard wrote:
> 
>> On Nov 30, 2007 5:59 PM, David Glasser <gl...@davidglasser.net> wrote:
>>> So, we have this merge tracking use cases/requirements doc:
>>>
>>> http://subversion.tigris.org/merge-tracking/requirements.html
>>>
>>> Which of these does current trunk (or "current trunk plus easy changes
>>> that we know how to do") support?
> 
> Ignoring some bugs in what we do have, what we don't support fully
> includes:
> 
> - Merging
>   - The parts of Repeated Merge dealing with reflected/cyclic merging
>     (issues #2897 and #2837)
>   - Block/Unblock Changeset

I recall the discussion to defer blocking to 1.6, which I don't support, but 
these two issues are the largest ones for the community in my mind.  I still 
suggest getting these into 1.5.

>   - Parts of "Handle Renames" (some of which cmpilato has in progress)

Nice, but not as important as the above two, but then I don't do tons of 
renaming and refactoring in my work.

While I understand we all want to get 1.5 out, it's going to be a long time (9+ 
months???) before 1.6 is close, unless we want to have a short 1.6 follow up, so 
I'd rather see the most common needs handled in 1.5.  The short release cycle I 
recall, has met resistance due to the pain to our users and downstream packagers.

Blair

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: merge tracking use cases

[David Glasser <gl...@davidglasser.net>]

On Nov 30, 2007 4:02 PM, Daniel Rall <dl...@collab.net> wrote:
> On Fri, 30 Nov 2007, Mark Phippard wrote:
>
> > On Nov 30, 2007 5:59 PM, David Glasser <gl...@davidglasser.net> wrote:

> > > Note that I don't see anything there that reminds me of #2897,  (Am I
> > > missing something?)
> >
> > I was updating Jack Repenning on all of this to get his take.  He said
> > that #2897 is the most common use case.  It is what everyone that uses
> > ClearCase UCM does (in fact it is officially called the "Standard Use
> > Model") and if Subversion does not have that feature then it does not
> > have merge tracking.
> >
> > I cannot really disagree.  I raised this back in June and I've raised
> > it several times since then.  It is hard to argue that we have
> > advanced the bar if a user cannot merge a branch back to trunk.
>
> Issue #2897 is a core part of the Repeated Merge use case.  Issue
> #2837 is coupled (almost the same), but the plan was to defer that
> part for post-1.5.

Is "merge to feature branch" and "merge from feature branch" really
the same operation though?

The way I see it, the first is saying "take revisions that represent
development on trunk and move them to the feature branch; I will need
to resolve conflicts (both textual and semantic)".

The second is saying "my feature branch right now is exactly what
trunk ought to be.  Make trunk look like my feature branch does now".

(Another way of looking at it is: the first is saying "integrate
changes from the trunk line of development into the feature line of
development"; the second is saying "this thing we used to call the
'feature line' should now be called the 'trunk line'".)

Today's merge-tracking achieves the first goal well.  The operation
accomplished by 2-URL merge today achieves the second goal.  Now, the
UI for 2-URL merge in the feature-branch-back-to-trunk case is
frustrating.  But I think all the information exists to calculate the
correct revs and such for the 2-URL merge operation, *today*.  Perhaps
all we need is a better UI around "merge-back-to-trunk", powered by
2-URL merge.

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org