On Aug 15, 2006, at 21:18, blackwater dev wrote:
> I have two repositories with development going on in each. One is
> a stable branch where we periodically make small changes and the
> other is our beta branch where we do larger development projects.
> When we make a small change to our stable branch, we want those
> changes to our beta branch as well. So, for example, if I have a
> file in beta with a lot of changes named allergies.cfm and someone
> else has made small changes for a quick bug fix in the stable
> branch to allergies.cfm, they need to get merged. I find that when
> I go to my working dev sandbox and do the command below, it gives
> me the latest stuff in my working copy from prod but removes all my
> dev changes in my local copy that are commited to dev but not yet
> to prod. I need to keep all the dev stuff and add the new changes
> from prod.
>
> svn merge http://10.1.1.15/svn/eDig/dev/include/allergies.cfm
> http://10.0.1.15/svn/eDig/prod/include/allergies.cfm
>
> If find if I switch the merge to do prod then dev, nothing happens
> at all.
Subversion is doing exactly what you told it to do, a.k.a. that's not
how you use the merge command.
The merge command is a kind of diff-and-patch. That means, first it
constructs a diff between two locations in the repository, then it
applies that to a third place -- your working copy. You've asked for
a diff between the version of a file on dev and the same file on
prod. That's not what you want, because it results in the problem you
observed.
Rather, you have some changes that were made to dev/include/
allergies.cfm. You would like to apply these changes to the prod
branch. So get a working copy of the prod branch:
svn co http://10.0.1.15/svn/eDig/prod
cd prod
Discover the revision number(s) in which the change(s) occurred that
you want to merge.
svn log http://10.1.1.15/svn/eDig/dev/include/allergies.cfm
Let's say you discover by reading the log that changes were made in
revision 5, 15, and 20, and that you want all of these changes merged
over. So you need to ask Subversion to compute the diff between
revision 4 (the revision before the first change took place) and 20
(the revision after all the changes you want have taken place) and
apply that to the copy of the file in the current working copy (of
prod):
svn merge -r4:20 http://10.1.1.15/svn/eDig/dev/include/allergies.cfm
include/allergies.cfm
Then you test the changes in your working copy. Then you commit the
working copy, making note in the log message that you've merged from
4 thru 20 of this file in dev into prod.
Usually I think people don't merge individual files like that, though
it should work fine. In Subversion, changes are usually revision-
based, not file-based. (Revision 5 might include changes to files
other than allergies.cfm, and since it was part of the same commit,
and you're supposed to use 1 commit for 1 task, then that other
change likely belongs with this one.) So if you read the log messages
of dev and decide that revisions 5, 15 and 20 are the three fixes
that you want to merge to prod, and you don't want to merge any of
the intervening revisions because they are for other unrelated new
features for example, then you would merge just those revisions into
the prod working copy:
svn co http://10.0.1.15/svn/eDig/prod
cd prod
svn merge -r4:5 http://10.1.1.15/svn/eDig/dev .
svn merge -r14:15 http://10.1.1.15/svn/eDig/dev .
svn merge -r19:20 http://10.1.1.15/svn/eDig/dev .
# test test test
svn ci -m "Merging revisions 5, 15 and 20 from dev into prod"
It's important to note in the log message exactly what you merged, so
that when you look at the log later you'll know, and you won't try to
merge the same thing twice. Subversion does not currently have merge
tracking so you have to keep track yourself of what you've already
merged.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 15 23:50:14 2006