On Mar 15, 2007, at 17:09, Andrew Close wrote:
> i created a new repository and committed one file to the trunk. my
> local workspace for the trunk is e:\test and the repository is
> file:///e:/repository/trunk
>
> i then created a branch based on the trunk and checked out the branch
> so i have two workspaces locally; one pointing to the trunk and one
> pointing to my branch.
>
> E:\test>svn copy file:///e:/repository/trunk
> file:///e:/repository/branches/branch1
>
> Committed revision 10.
>
> in the branch workspace i made several changes to the file and
> committed. my local workspace for my branch is e:\test1.
> i then attempted to merge the changes from the branch to the trunk:
>
> E:\test1>svn merge file:///e:/repository/branches/branch1
> file:///e:/repository/trunk
> e:\test --dry-run
>
> <no output/>
>
> no output was given so i assume that there would be no changes merging
> this direction..?
That is not how svn merge works.
svn merge creates a diff, then applies it. You need to tell it what
to create the diff between, and where to apply it.
You want to have the difference between the branch at the revision in
which it was created (10) and the current revision (whatever it is,
let's say 42) committed to a working copy of the trunk. So go into
your working copy of the trunk (with no other uncommitted changes)
and say
svn merge -r10:42 file:///e:/repository/branches/branch1
Then test the working copy. Then commit the change:
svn ci -m "Merging r10-42 of branch1 into trunk"
> let's try again, slightly different:
>
> E:\test1>cd ..\test
>
> E:\test>svn merge -r 8:11 e:/test@8 . --dry-run
>
> <no output/>
>
> E:\test>svn merge -r 11:8 e:/test@8 . --dry-run
>
> <no output/>
>
> so both workspaces contain the same file, but the file is slightly
> different since i made some changes to it on the branch. but when
> merging with the previous command nothing seems to happen in either
> direction...
You want to use a URL to the repository, not a working copy path.
Also, your peg revision @8 is weird and not relevant here. To
understand when using @[REV] might be useful, read about the
difference between peg and operative revisions in the book:
> let me try again, slightly differently:
>
> E:\test>svn status
>
> <no output/>
>
> E:\test>svn merge e:/test@11 e:/test1@11 e:/test
> U E:\test\HNSClaimNegotiationResultHandler.java
>
> E:\test>svn status
> M HNSClaimNegotiationResultHandler.java
>
> ahh! ok, this time something happened. since i didn't do a dry-run i
> can diff the two files. i used winmerge to compare the two files and
> they are exactly the same.
Ok, so what you've asked for there is to receive a diff between e:/
test (the working copy of the trunk) and e:/test1 (the working copy
of the branch) and apply it to e:/test (the working copy of the trunk).
This seemed to work for you in this very basic test, but is not what
you want to use in practice, because not only would it *add* to the
trunk working copy everything you had done on the branch, it would
also *remove* from the trunk working copy anything that you had only
done in the trunk.
> ok, now i make changes to both files on the same line of the source
> and attempt the previous merge command (after committing the changes).
>
> the file is modified again and when i compare them in winmerge the
> files are identical.
> this time i expected a conflict since both files had been modified on
> the same line in their respective branches. where am i going wrong?
> or is my understanding of the merge still incorrect? :) (most likely)
>
> i assumed that if two lines of the same file from different branches
> are different you would get a conflict when merging. similar to what
> would happen when two developers attempt to commit the same file with
> changes on the same lines without updating first.
> does the merge 'merge' changes or overlay them? i'm sure that i'm
> missing the obvious here.
>
> and the three merge commands, do they all do the same thing but in
> different ways? or is there a better time to use one or the other
> based on situation?
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 16 07:26:32 2007