Gale, David wrote:
> 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'".
Hold it there: why is renaming a file "trivial"? It's not: every reference
to that file, anywhere in that software, may have to be changed with it.
That means there are associated changes with the renaming, which the
Subversion tracking may not be able to handle gracefully: that's especially
true with source files.
> 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.
I agree it could be better, but if you really think about what is associated
with it, you start to see why it does it this way, as a "duplicate", then a
"remove".
>>> 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).
That's why you use your own branch! Getting "outstanding edits" preserved is
a huge problem: The subversion "use your own darn branch!" approach is
supportable, in a way that "force outstanding checkouts to be updated from
here" would become nearly impossible to manage. (I've had to deal with that
approach, under CVS and Perforce: it's painful.)
---------------------------------------------------------------------
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:23:48 2006