That makes sense. However, it does not explain how I got the conflict -
I followed exactly the steps below. I dont see how SVN could've decided
that the same portion of the file was being edited simultaneously. I was
doing the steps below sequential. My best guess is the branch being
created from a non-head revision of trunk somehow bothered it?
thanks
-Siddharth
________________________________
From: Campbell, Matthew A [mailto:Matthew.Campbell@relizon.com]
Sent: Friday, July 16, 2004 1:20 PM
To: Ram, Siddharth; subversion mailing list (E-mail)
Subject: RE: SVN Copy problem
AFAIK, you can easily get merge conflicts regardless of who made which
changes - even if it's you both times. The person doing the change is
irrelevant, the conflict is due to the same portions of the same file(s)
being edited simultaneously, therefore automatic patching can't cope.
Somebody feel free to correct me if I'm wrong...
-----Original Message-----
From: Ram, Siddharth [mailto:sram@qualcomm.com]
Sent: Friday, July 16, 2004 4:20 PM
To: subversion mailing list (E-mail)
Subject: SVN Copy problem
I'm getting a conflict where I do not expect to get a conflict.
Here's the situation (done using the Perl API)
1. I create a file foo.c , add and commit it to trunk
2. I make some changes in foo and commit it back to trunk.
3. I make some more changes in the working copy.
4. I decide to save working copy changes in a branch. So first I
create a pristine copy of trunk using (the perl API equivalent of)
svn copy -r 6 http://svn/rep/trunk/foo.c
http://svn/rep/branch/foo.c
(where the revision is not the head )
5. I switch to the branch
6. I commit my changes, expecting that my working copy changes
to rev 6 would get commited to the branch. Instead , I get a merge
conflict !
How could be happening to do this? If SVN sees changes all by
the same user, it should never declare a conflict, right ?
thanks
Siddharth
Received on Fri Jul 16 22:41:27 2004