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.
> 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.
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 25 17:56:44 2006