On Jul 24, 2007, at 12:44, Jeff Green wrote:
> My company has just recently migrated over to SVN and we are in the
> process of getting the repository up to date. As we've been
> checking in
> our code, we've been having some very weird behaviour with respect to
> file merges.
>
> For example, we had an xml file in the repository. It's initial
> check-in
> contained the text:
>
> <Key id="1100">Number of duplicate unit IDs exceeds allowed value.</
> Key> </Translation>
>
> Working off this base, another employee committed a change:
>
> <Key id="1100">Number of duplicate unit IDs exceeds allowed value.</
> Key>
> <Key id="1104">There are currently no transfers stored in the
> handheld to download</Key> </Translation>
>
> Also working off the base, I committed:
>
> <Key id="1100">Number of duplicate unit IDs exceeds allowed value.</
> Key>
> <Key id="1101">Two or more donors were found with the specified ID.
> Please contact your site administrator for assistance.</Key>
> <Key id="1102">Two or more devices were found with the specified
> ID. Please contact your site administrator for assistance.</Key>
> <Key id="1103">Two or more objects were found with the specified
> ID. Select either "Donor" or "Device" to refine the search.</Key>
> </Translation>
>
> When I tried to commit, I was warned of conflicts (appropriately) and
> then ran an update on the xml file. Subversion automerged the file
> and in the process over wrote the first commit and replaced it with
> my changes. As far as I've been able to figure out, this happened
> because SVN found similiarities between my co-worker's changes
> and my own and assumed that my change had been to simply
> modify the line that my co-worker had committed.
>
> This confuses me however, as my expectation would have been that
> SVN would see two lines that were both different from the base and
> would detect a conflict.
I agree. I would also have expected a conflict to occur at this
point. Subversion should definitely not be throwing out lines during
the merge.
> So all that background aside, I'm wondering if anyone has any thoughts
> on what SVN actually did here and why it occurred. This has since
> happened with other files I've checked in as well, with SVN over-
> writing
> other committed code instead of finding a conflict between lines.
Are you using the latest Subversion, 1.4.4? What OS it on the server
and what OS is on the client? What repository access method do you use?
Can you show us a reproduction recipe that begins with "svnadmin
create" and ends with the problem? It's hard for us to see the
problem otherwise.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 25 12:09:55 2007