You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Richard In Public <ed...@blueyonder.co.uk> on 2003/04/01 18:23:35 UTC
Advice Needed: Merging Branch back into Trunk
Hi
I'm trying to merge a branch into the trunk but do not understand the
results. I've not been able to figure it out using the Subversion guide or
mailing lists.
What I'm trying is the following:
1. Create a new directory into which I checkout .../branches/mybranch
2. Merge the branch into this wc, thus (executed within the new directory):
svn merge http://myserver/svn/myrepos/trunk
http://myserver/svn/myrepos/branches/mybranch .
3. Commit this directory.
This appears to work ok and an visual (browser) inspection of the repository
seems to show success. However, if I repeat this process (in a new
directory) I get:
D images/BrownBox.jpg
D images/BrownBox.jpg
A images/BrownBox.jpg
D images/buy-now.jpg
D images/buy-now.jpg
A images/buy-now.jpg
D images/Logo.jpg
D images/Logo.jpg
A images/Logo.jpg
D images/suppliers/heav.jpg
D images/suppliers/heav.jpg
A images/suppliers/heav.jpg
D images/suppliers/caco.jpg
D images/suppliers/caco.jpg
A images/suppliers/caco.jpg
D images/suppliers/gift.jpg
D images/suppliers/gift.jpg
A images/suppliers/gift.jpg
D images/suppliers/shsm.jpg
D images/suppliers/shsm.jpg
A images/suppliers/shsm.jpg
D images/suppliers/deil.jpg
D images/suppliers/deil.jpg
A images/suppliers/deil.jpg
D images/CalypsoProduct.jpg
D images/CalypsoProduct.jpg
A images/CalypsoProduct.jpg
C images/products/ficc/products/002.jpg
D images/products/ficc/products/L002.jpg
D images/products/ficc/products/L002.jpg
A images/products/ficc/products/L002.jpg
D images/products/caco/products/caco001.jpg
D images/products/caco/products/caco001.jpg
A images/products/caco/products/caco001.jpg
D images/products/eopr/products/024.jpg
D images/products/eopr/products/024.jpg
A images/products/eopr/products/024.jpg
D images/products/eopr/products/025.jpg
D images/products/eopr/products/025.jpg
A images/products/eopr/products/025.jpg
D images/products/eopr/products/L024.jpg
D images/products/eopr/products/L024.jpg
A images/products/eopr/products/L024.jpg
D images/products/eopr/products/L025.jpg
D images/products/eopr/products/L025.jpg
A images/products/eopr/products/L025.jpg
D images/products/eopr/products/Eo001.jpg
D images/products/eopr/products/Eo001.jpg
A images/products/eopr/products/Eo001.jpg
D images/products/eopr/products/Eo002.jpg
D images/products/eopr/products/Eo002.jpg
A images/products/eopr/products/Eo002.jpg
D images/products/eopr/products/Closer.jpg
D images/products/eopr/products/Closer.jpg
A images/products/eopr/products/Closer.jpg
D images/products/inwi/products
D images/products/inwi/products
svn: Unmergeable scheduling requested on an entry
svn: Can not add 'images/products/inwi/products/products' to a parent
directory scheduled for deletion
1. Am I going about this the wrong way?
2. How do I get my trunk to precisely mirror a branch?
3. Is there a way to force merge to always overwrite local copies?
TIA,
Richard Hoberman
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Advice Needed: Merging Branch back into Trunk
Posted by Tom Lord <lo...@emf.net>.
> So, personally, I think it makes sense to keep that "whole
> project" merge history automatically. It _can_ be done
> without deep changes to svn itself -- i.e., it can be
> regarded as a layer over svn. Among the payoffs of that
> approach is that it can buy a useful form of distributed
> repositories for not-quite-free-but-cheap (i.e., by
> recording that history in a repository-neutral way).
Hmmm, that's pretty tantalizing :-).
Can you describe this record-keeping layer in more detail
(i.e., enough detail to implement)?
Well, you can find a surprisingly useful prototype (not tied to svn in
any way) at "regexps.srparish.net/www" :-) I can try to give you
some quick hints to orient you around that code.
I think that the tentative idea I have in mind might make the most
sense from the svn perspective if initially regarded as a set of
(semi-automated) conventions for how you lay out a repository.
That is: at it's core, svn is completely free-form about repository
layout and has it's particular concepts of file and directory history.
But then on top of that, one tends to build conventions -- such as how
to layout branches, and how to use tags, and how to organize multiple
projects in a single repository. (At least that's my understanding.)
Ok, well, looking at that Other Project mentioned above: you can
squint at it and subtract out the details of the particular
implementation -- and regard it as a big collection of conventions and
standards-in-waiting. Standards about, for example, how to name
development lines and revisions in a repository-independent way;
standards for how to record (in the source tree) the history of merges
between those repository-independent development lines; etc.
Putting these together, I see the (not fully developed) idea of
mapping the conventions from the Other Project into the layout of a
svn repository. For example, where the Other Project might store a
revision in its low-tech archives by squirreling away a .tgz tar file
of the changeset, in svn, the analogous operation would consist
(approximately) of forming a suitably named tag (directory copy). In
BK parlance (I'm informed), this mechanism would be comparable to the
checkin/commit paradigm ("BK checkin" being _roughly_ a svn commit --
though svn commits are fancier; "BK commit" being _roughly_ -- form
that tag that groups a set of checkins into a globally named
changeset, suitable for use in review, distribution, and fancy
merging).
"Distribution for free" falls out of that not by trying to fully
distribute complete svn repositories -- but by distributing the
high-level development lines that are defined by the various naming
conventions. That is -- you get distribution right where you need it:
at the project management level rather than the svn schema level.
The "record-keeping layer" you're asking about has a few elements.
There's a global namespace for development lines; there's an
inventory mechanism for identifying files within revisions of those
development lines; there's a logging mechanism for keeping a record
of which changesets have been applied to what trees (in terms of the
global namespace). As far as core-svn is concerned -- all that stuff
is just additional source files in project trees.
A crude approximation might be: when I merge trunk@X into branch I add
a note to the file branch/merges. And then later, when I want to do a
history sensative merge or compute an interesting changeset, that file
branch/merges is handy. In the Other Project -- that "branch/merges"
file is replaced by a tree of RFC822ish log messages whose header
fields automatically accumulate the merging data (along with a bunch
of other stuff).
(Another feature this can get you "for free" is a mechanism comparable
to CVS modules -- but a bit more featureful. The global namespace
gives you handy names for separate projects within a repository. You
can define "modules" (we call them "configurations") in terms of that
namespace, and keep versioned records of those modules and how they
relate to releases.)
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Advice Needed: Merging Branch back into Trunk
Posted by kf...@collab.net.
Tom Lord <lo...@emf.net> writes:
> So, personally, I think it makes sense to keep that "whole project"
> merge history automatically. It _can_ be done without deep changes to
> svn itself -- i.e., it can be regarded as a layer over svn. Among the
> payoffs of that approach is that it can buy a useful form of
> distributed repositories for not-quite-free-but-cheap (i.e., by
> recording that history in a repository-neutral way).
Hmmm, that's pretty tantalizing :-).
Can you describe this record-keeping layer in more detail (i.e.,
enough detail to implement)?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Advice Needed: Merging Branch back into Trunk
Posted by Tom Lord <lo...@emf.net>.
> less trivial. It doesn't help that svn rev ids are global rather than
> sequentially allocated per development line -- so, after a few years,
> my corporate repository is presumably going to have 6-digit ids and so
> forth -- and good luck building a nice graphical map of the merge
> histories of my various project branches.
I would like to point out that perforce also has global change numbers.
In many ways its a requirement of having atomic commits
I'm not so sure about that. Suppose that your repository contains
multiple projects. You don't need to have numbers that totally order
the commits in all projects -- you only need numbers that order the
commits within each separate project.
- without global
change #s, you'd need 2 pieces of data: which portion of the repo and
the change #.
You effectively need that anyway. In svn's case, a path plus a rev id.
If change #s are sequentially allocated starting at 0 per project
(e.g. project path), that makes them easier to think about and type
and speak over the phone and manipulate in scripts (without server
roundtrips) and so forth. Consider the simple question of laying out
a report about the changes made to project foo (path /trunk/foo)
between @X and @Y: Do you need (1 + Y - X) rows? or do you need to
ask a server how many rows you need?
I work at a company with a large p4 repository. We're migrating from 1
repo to another right now, but the old p4 db has 5 digit change
numbers. I think we're cresting 250,000 soon.
Sure. I've heard of significantly larger-scale repositories, too.
And I don't think they'll even be all that rare -- e.g., repositories
for "complete GNU/Linux distributions".
I'm not the actual p4 admin, so I'm not sure if that is causing any
problems. I think the actual issue of dealing with SO many changes
is causing the problem, not the actual size of the change number.
I'm imagining things such as a phone conversation between two
programmers: "A: I merged that in 192158. B: [typing in background]
you said one nine two five one eight?"
As for your other comments, re: branch merging, I concur completely. We
have extremely complex merges, usually we integrate the mainline branch
to a release branch, work on that, integrate a few minor things from
mainline->release or release->mainline, and then a few weeks later we
start all over again. I imagine this is a fairly common scenario. CVS
can't remotely handle this,
Just as a point of trivia -- if you very carefully, wisely, and
patiently use use tags, CVS _can_ handle this -- just not very
gracefully or efficiently or with support for distribution.
so SVN is so far way up on CVS, but why stop at replacing CVS? Why
not provide a 'p4-lite-ish' tool?
What do you mean "lite"? :-)
For the sake of "full disclosure": on the arch-users list (I'm the
author of arch), we take it as axiomatic that svn is broken and
foolish and arch conquers all. Here on svn's dev list, I presume we
take it as axiomatic that svn is very useful.
In real life: while I have reservations about some of the
implementation choices of both systems, I find it interesting that the
good parts of each have only slightly overlapping features and that
the union of those feature sets adds up to something that leapfrogs
every other system I've heard of.
Something that is useful for
medium complexity project (50-150 developers?). To get there, I'd
say handling all the complex merges would be key.
As for your idea, very interesting, would you care to expand it greatly
?
It's really hard to compress into a brief email message especially
when my financial TTL is so short.
Join arch-users@fifthvision.net (poke around at arch.fifthvision.net
to find the detailed info about the list).
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Advice Needed: Merging Branch back into Trunk
Posted by ryan <ry...@netidea.com>.
> less trivial. It doesn't help that svn rev ids are global rather than
> sequentially allocated per development line -- so, after a few years,
> my corporate repository is presumably going to have 6-digit ids and so
> forth -- and good luck building a nice graphical map of the merge
> histories of my various project branches.
>
Hi,
I would like to point out that perforce also has global change numbers.
In many ways its a requirement of having atomic commits - without global
change #s, you'd need 2 pieces of data: which portion of the repo and
the change #.
I work at a company with a large p4 repository. We're migrating from 1
repo to another right now, but the old p4 db has 5 digit change
numbers. I think we're cresting 250,000 soon. I'm not the actual p4
admin, so I'm not sure if that is causing any problems. I think the
actual issue of dealing with SO many changes is causing the problem, not
the actual size of the change number.
As for your other comments, re: branch merging, I concur completely. We
have extremely complex merges, usually we integrate the mainline branch
to a release branch, work on that, integrate a few minor things from
mainline->release or release->mainline, and then a few weeks later we
start all over again. I imagine this is a fairly common scenario. CVS
can't remotely handle this, so SVN is so far way up on CVS, but why stop
at replacing CVS? Why not provide a 'p4-lite-ish' tool? Something that
is useful for medium complexity project (50-150 developers?). To get
there, I'd say handling all the complex merges would be key.
As for your idea, very interesting, would you care to expand it greatly
?
Regards,
-ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Advice Needed: Merging Branch back into Trunk
Posted by Tom Lord <lo...@emf.net>.
> You need to compare /branch@(Y+1) with /branch@HEAD.
That's not right, it will miss any @Y to @(Y+1) change. If
the first merge is @X to @Y, the next merge should be @Y to
@Z.
It gets more complicated/"fun" if you also:
(a) merge back and forth between trunk and branch
(b) take uncommitted changes in the working directory into account
(c) care about adjusting the relative priorities of the three
sets of changes in play (trunk, branch, and wd) [*]
For extra fun, throw in:
(d) over time, you alternate between cherry-picking and full merging
between trunk and branch
Step (a) makes it trickier to identify the appropriate
baselines to compare.
Steps (b) and (c), taken together, give you multiple different merge
techniques to choose from.
All steps, though (d) makes it really obvious, suggest strongly that
you want ultimately to automate bookkeeping of the merge history of
"whole project trees" -- not just individual files and directories.
This is a _little_ tricky to reconcile with svn's project-less model
and support for "mixed revision" working directories.
One big weakness I see here for svn is bookkeeping. My understanding
is that it's up to users to keep track of or figure out the revision
numbers that are relevant to project merging. Given all those numbers
and a map of the history of past merges, it's just a few minutes of a
casual puzzle to figure out the right combination of `co', `merge',
and `switch' commands to do an "intelligent, history-sensitive merge"
-- but keeping or figuring out those numbers and that merge history is
less trivial. It doesn't help that svn rev ids are global rather than
sequentially allocated per development line -- so, after a few years,
my corporate repository is presumably going to have 6-digit ids and so
forth -- and good luck building a nice graphical map of the merge
histories of my various project branches.
So, personally, I think it makes sense to keep that "whole project"
merge history automatically. It _can_ be done without deep changes to
svn itself -- i.e., it can be regarded as a layer over svn. Among the
payoffs of that approach is that it can buy a useful form of
distributed repositories for not-quite-free-but-cheap (i.e., by
recording that history in a repository-neutral way).
-t
[*] "adjusting the relative priorities of changes" means, for example,
regardless of where you are going to commit: are you starting with a
trunk tree and applying patches? or starting with a branch tree?
What might those priorities matter? Well, for example, let's suppose
that trunk is merging back and forth from _multiple_ branches. On a
previous merge from trunk into branch, a bunch of conflicts were
resolved in favor of the version on branch (because, say, trunk and
branch had made conflicting API changes -- or branch had decided to
not yet pick up an API change merged into trunk from elsewhere). At a
later date, branch is ready to pick up that API change. If you start
with a trunk tree and patch it for changes on branch, you get just a
few conflicts -- if you start with a branch tree and patch it for
changes on trunk, you get many conflicts. (This isn't theoretical --
I've actually experienced this conflict differential in bidirectional
merges.)
A second reason priorities matter is if you switch from
conflict-marker to .rej-style conflict resolution -- which tree's
changes get shoved off into .rej and which are in the source?
Personally, I find the .rej style often more convenient -- but that
has as much to do with my personal emacs habits as anything else.
Other people are presumably have the opposite experience. (In
particular, I've found it easy to go through and look at ".rej" files
and then just delete them because I know they're not important --
that's easier than editing the corresponding files, finding the
conflict markers, deleting the markers, and deleting the correct one
of the two alternatives.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Advice Needed: Merging Branch back into Trunk
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> $ svn co http://.../trunk
>
> $ svn merge http://.../branch@X http://.../branch@Y .
>
> $ svn commit
>
> X is the revision in which /branch was first created, and Y is
> typically HEAD.
>
> If you repeat this merge later on, you have to be careful not to
> remerge changes that were applied already.
OK so far.
> You need to compare /branch@(Y+1) with /branch@HEAD.
That's not right, it will miss any @Y to @(Y+1) change. If the first
merge is @X to @Y, the next merge should be @Y to @Z.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Advice Needed: Merging Branch back into Trunk
Posted by Ben Collins-Sussman <su...@collab.net>.
"Richard In Public" <ed...@blueyonder.co.uk> writes:
> Run from within the checked out trunk svn merge -r 33:HEAD
> http://europad/svn/henrys-brown-boxes/branches/hostway .
>
> responds with:
>
> svn: RA layer request failed
> svn: REPORT request failed on '/svn/henrys-brown-boxes/branches/hostway'
> svn: The REPORT request returned invalid XML in the response: Unknown XML
> element `error (in DAV:)'. (/svn/henrys-brown-boxes/branches/hostway)
No, I think the immediate problem here is issue #1201: "200 httpd
response contains <error> in body".
> I suspect that this is because revision 33 was created with an earlier
> version of SVN. This seems to be confirmed by the fact that this command
> works if I use substitute version 55 for version 33.
>
> Instructions in The Guide (which I've just reread) require that the old
> repository is exported with the earlier version of SVN. Unfortunately, I
> ahven't been doing so so my repository has been modified by quite a few SVN
> versions. Is there any way of recovering from this problem?
Um, svn clients don't affect the format of the repository. When the
repository db schema changes, you'll definitely know: you're forced
to do a dump/reload of all data.
I think the problem here is that the path /svn/.../branches/hostway
doesn't exist in revision 33. Is that the case?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Advice Needed: Merging Branch back into Trunk
Posted by Richard In Public <ed...@blueyonder.co.uk>.
Hi
1. Thanks for busting yet another of my subversion fallacies...
2. I'm still having the following problem:
Run from within the checked out trunk svn merge -r 33:HEAD
http://europad/svn/henrys-brown-boxes/branches/hostway .
responds with:
svn: RA layer request failed
svn: REPORT request failed on '/svn/henrys-brown-boxes/branches/hostway'
svn: The REPORT request returned invalid XML in the response: Unknown XML
element `error (in DAV:)'. (/svn/henrys-brown-boxes/branches/hostway)
I suspect that this is because revision 33 was created with an earlier
version of SVN. This seems to be confirmed by the fact that this command
works if I use substitute version 55 for version 33.
Instructions in The Guide (which I've just reread) require that the old
repository is exported with the earlier version of SVN. Unfortunately, I
ahven't been doing so so my repository has been modified by quite a few SVN
versions. Is there any way of recovering from this problem?
TIA,
Richard
----- Original Message -----
From: "Ben Collins-Sussman" <su...@collab.net>
To: "Richard In Public" <ed...@blueyonder.co.uk>
Cc: <de...@subversion.tigris.org>
Sent: Tuesday, April 01, 2003 7:44 PM
Subject: Re: Advice Needed: Merging Branch back into Trunk
> "Richard In Public" <ed...@blueyonder.co.uk> writes:
>
> > What I'm trying is the following:
> >
> > 1. Create a new directory into which I checkout .../branches/mybranch
> > 2. Merge the branch into this wc, thus (executed within the new
directory):
> >
> > svn merge http://myserver/svn/myrepos/trunk
> > http://myserver/svn/myrepos/branches/mybranch .
> > 3. Commit this directory.
>
> This is a common fallacy.
>
> Suppose you have /trunk, then copy it to /mybranch. Then you make
> changes on /mybranch for a while, and want to merge the branch back
> into the trunk.
>
> 'svn merge' compares two URLs, and merges the diffs into a working
> copy as a local mod.
>
> That means that to begin with, you need a working copy of /trunk.
>
> Then you want to compare *two versions of the branch* to generate the
> diffs. You do *not* want to compare /trunk and /branch, which is what
> you're doing above.
>
> In other words, you want to do something like this:
>
> $ svn co http://.../trunk
>
> $ svn merge http://.../branch@X http://.../branch@Y .
>
> $ svn commit
>
> X is the revision in which /branch was first created, and Y is
> typically HEAD.
>
> If you repeat this merge later on, you have to be careful not to
> remerge changes that were applied already. You need to compare
> /branch@(Y+1) with /branch@HEAD.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Advice Needed: Merging Branch back into Trunk
Posted by Ben Collins-Sussman <su...@collab.net>.
"Richard In Public" <ed...@blueyonder.co.uk> writes:
> What I'm trying is the following:
>
> 1. Create a new directory into which I checkout .../branches/mybranch
> 2. Merge the branch into this wc, thus (executed within the new directory):
>
> svn merge http://myserver/svn/myrepos/trunk
> http://myserver/svn/myrepos/branches/mybranch .
> 3. Commit this directory.
This is a common fallacy.
Suppose you have /trunk, then copy it to /mybranch. Then you make
changes on /mybranch for a while, and want to merge the branch back
into the trunk.
'svn merge' compares two URLs, and merges the diffs into a working
copy as a local mod.
That means that to begin with, you need a working copy of /trunk.
Then you want to compare *two versions of the branch* to generate the
diffs. You do *not* want to compare /trunk and /branch, which is what
you're doing above.
In other words, you want to do something like this:
$ svn co http://.../trunk
$ svn merge http://.../branch@X http://.../branch@Y .
$ svn commit
X is the revision in which /branch was first created, and Y is
typically HEAD.
If you repeat this merge later on, you have to be careful not to
remerge changes that were applied already. You need to compare
/branch@(Y+1) with /branch@HEAD.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org