On Dec 5, 2007 2:06 PM, David Glasser <glasser@davidglasser.net> wrote:
> We decided to start by implementing an operation that works only in a
> special case (which is carefully checked) and throws an error
> otherwise; the idea is that we can then (before or after 1.5 release)
> generalize it by offering support for some of the things that start as
> error cases.
>
> The specific case we're starting by handling (and the bulk of this is
> done; we're just ironing out bugs) is:
>
> * The working copy you're merging into is a pristine, single-rev,
> unswitched checkout: ie, it's something you could get as a fresh
> checkout of some URL@REV
>
> * The branch you're merging from has (according to mergeinfo) all of
> the changes on that URL up to REV integrated (using cmpilato's
> merge source normalization / location segments)
>
> In that case, you can just type
>
> $ svn merge url://to/feature-branch
>
> and it will do the right thing. We will also make it add mergeinfo
> for this merge.
In general, I am OK with this approach. Dan and I went down this same
patch back in May/June. Back then I think we discarded it because the
underlying 2-URL merge that would be executed would not update
mergeinfo and at the time we didn't see that being done. As you point
out cmpilato has made this more possible now, and even has a branch
where it has been implemented (today).
http://svn.collab.net/repos/svn/branches/better-two-url-merges/
My concern is that these REV requirements in the WC are too tight.
1. Must have an unswitched and complete checkout. I am OK with this,
I imagine most people would be.
2. Must be a single revision. I am so-so on this. It is a good idea,
and not too hard, so I can live with it.
3. Must be the last revision that the branch was synched with. This
one I have a problem with.
This last option is just another form of manual merge tracking and
will make the UI/workflow suck. You have a proposed workflow using
two working copies where it doesn't sound too bad, but it does not
sound terribly realistic either. Let's remember sussman's 80%/20%
blog post.
Here is a typical work flow.
I am working on my feature branch and periodically staying in synch
with trunk by just running:
svn merge
svn ci
I did not have to look at revisions, everything just worked itself
out. Merge tracking at its best. At some point I feel I am ready to
go back to trunk. I might do one last synch and then spend some doing
testing again, or I might want to just go back to trunk and work out
conflicts and do final tests in my trunk WC. In either case, I do not
readily know the revision of trunk I last merged into the branch. You
are saying that I have to now look at the merge history to determine
this information, and then run:
svn switch -r THE-REV url://trunk
svn merge url://branch
I think that I ought to be able to just:
svn switch url://trunk
svn merge url://branch
The code is already going to determine the last revision from trunk
that was merged into branch and then run a 2-URL merge. The merge API
itself can handle the WC being at either revision. Why create this
artificial barrier that ruins the user experience and UI?
On IRC, it was said that you would not want to clobber changes. I do
not get this. It is a merge. At worst it would create some conflicts
that would have to be resolved. Those same conflicts would just be
produced at commit time (would be out of date) when I update to HEAD.
Figure out a way where the revision of the WC is not critical to this
process and I think we have a good solution here.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 5 22:20:26 2007