Nico Kadel-Garcia wrote:
> Jim Sheldon wrote:
>> Hello everyone, this is my first post to this mailing list.
>>
>> I have encountered a problem at work where we user subversion for our
>> software projects. The problem arises when the following occurs:
>>
>> 1. file1.txt is moved/renamed (using subversion commands, not the
>> local filesystem) on system A to file2.txt.
>>
>> 2. System B then makes changes to file1.txt and commits them.
>>
>> 3. System A runs 'svn update' before commiting its changes.
>> file1.txt is retreived from the server with modifications from
>> System B.
>>
>> At this point users of both System A and B have to communicate to
>> merge their changes into file2.txt.
>
> This is why the ghods invented branches: so that System A and B can
> each have their own branches, so they can each avoid stepping on each
> other this way. Then when they're done, they merge their changes back
> to the trunk.
A trivial change like renaming a file shouldn't require a branch. And I
don't think branches solve this problem--I did a quick test where I
created a file (bar.txt) in trunk, copied it to two branches, edited it
in one and renamed it in the second; merged the rename into trunk first,
and then attempted to merge the edit in; "Skipped missing target:
'bar.txt'".
The problem is that Subversion doesn't track renames properly. If it
knew that the file had been removed, rather than knowing that a file was
deleted while a second file was added, the merge I tested as well as the
original poster's scenario would both work as expected.
>> My question is, shouldn't subversion be smart enough to know that
>> when the user on System A runs 'svn update', file1.txt should not be
>> downloaded, the user should be warned that a modification was made to
>> file1.txt after it was moved file2.txt, but before the move was
>> committed to the repository?
>
> Not really, in my personal opinion: it's very difficult for
> Subversion and its ancester, CVS, to know who might have something
> checked out or all the different possible locations of checkouts, on
> the same system or on different systems, which might need to be
> cross-notified this why. If you're going to do this, you really need
> to do "svn update" before doing "svn commit" of anything.
That's not what Jim was asking. Subversion claims to handle renaming
files, and it does somewhat (revision history is still accessible after
a file is renamed), but update and merge show that the current system
still has problems. Jim is asking why svn update doesn't handle file
renames smoothly; having the users do svn update every time they blink
won't change this.
>> I hope this makes sense. If this is a known problem, I was unable to
>> find anything relating to it in the manual, or in various google
>> searches.
>>
>> Thanks!
>
> That's why, if you have to both work on the same branch at the same
> time, both systems should do an update *before* comtting.
Again, that won't fix anything. As subversion currently stands,
renaming files should be done with extreme caution--you basically need
to ensure that no one has outstanding edits on the file being renamed,
and then have everyone update their working copies immediately after the
rename to make sure that things go smoothly. Annoying, but it's better
than CVS (under which users were strongly discouraged from ever renaming
files).
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 25 19:10:30 2006