[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: merging - VSS to SVN...

From: Andrew Close <aclose_at_gmail.com>
Date: 2007-03-15 23:09:47 CET

On 3/15/07, Andrew Close <aclose@gmail.com> wrote:
> On 3/14/07, Andy Levy <andy.levy@gmail.com> wrote:
> > On 3/14/07, Andrew Close <aclose@gmail.com> wrote:
> > > Hi all,
> > >
> > > we're currently using VSS and are planning on migrating to SVN. at
> > > the moment we have one project using SVN and the rest of the company
> > > is still using VSS; we're the guinea pigs. :)
> > > one problem we're facing is that some of the code we're using
> > > straddles VSS and SVN.
> > > Project A started a new codebase in SVN composed of some existing code
> > > and lots of new code. Project B is production code that still lives
> > > in VSS for the rest of the dev team to carry on with their normal
> > > tasks. when team B deploys to production team A wants to merge the
> > > updates into their codebase so they don't fall too far out of sync.
> > > this is really a simplification of what's currently going on, but i
> > > think illustrates our problem.
> > >
> > > what we've attempted to do is create a branch in SVN off of the
> > > Project A codebase. checkout branch A' to a local workspace. overlay
> > > the A' workspace with the source from the VSS repository and
> > > add/commit so that A' now matches what came from VSS. we then attempt
> > > to merge branch A' with A, but the merge appears to just overwrite the
> > > code in A with A' even though there should be conflicts that need
> > > resolving.
> >
> > People will be able to give you a lot more specific advice if you
> > provide the actual merge command you're using.
> >
> > I'm guessing you're probably using svn merge <branch A> <A> where you
> > should be using svn merge -rLAST_REV_BEFORE_LATEST_VSS:HEAD <branch A>
> > <A>
> >
> > Think of merge as "calculate what changed on <branch A> between these
> > 2 revisions and apply that to <A>".
>
>
> Andy,
>
> thank you for the reply.
> originally i was using TortoiseSVN to do the merge. after your email
> i switched to the cli and tried the command you mentioned. let me
> walk you through the steps:
>
> i checked out the branch that i wanted to merge the VSS code into
> into a fresh workspace. this branch is at version 32.
>
> i copied the code from the VSS branch and pasted it on top of my
> version 32 SVN branch. this added several new files and modified many
> others.
> i committed these changes and am now at version 35.
>
> from the cli i tried - C:\>svn merge -r 32:35 c:\testworkspace@35
> c:\testworkspace
> assuming that this would take the source from version 32 and merge it
> into version 35 generating several conflicts that i would need to
> resolve.
> however, several files were added and many more were modified, but i
> didn't see any conflicts. so it looks like the merge just overlaid
> the source instead of merging it.
> is there a step i'm missing in there somewhere? or am i not
> completing the process? (leaving off a step at the end)

i've attempted a simpler example to see if i could figure out what was
going on. :) but i'm still a bit flummoxed.

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..?

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...

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, 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?

thanks for helping me clear this up.
andy

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 15 23:10:18 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.