Nico Kadel-Garcia wrote:
> 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.
A file rename is a trivial change because it is small, and affects a
single file. A file rename combined with multiple modifications to
other files to reflect the rename is non-trivial, as you point out.
They are two different beasts. The issue is not what happens with other
files that may or may not be broken by the renaming of a single file
(modifying a single file can also break other files, especially if it's
a common library file)-subversion is not designed (nor could/should it
be) to examine the entire project and make sure that the user has indeed
fixed all of the places that are affected by any given change.
Subversion doesn't know or care whether something should be an
"associated change" or not.
>> 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".
Such as? True, there are many edge cases (for instance, if users A and
B check out a file, user A modifies it, user B copies it three times and
checks in, and then user A updates, should those three copies be updated
with user A's modification to the original?) I never said that
supporting true renames was *easy*, just that it should be done. Or
else subversion shouldn't claim to support renames, as that tends to
lead to confused users when they discover that this scenario doesn't
work.
>>>> 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.)
Like I said, I tested with branches, and it doesn't work:
# echo 'hello' > trunk/bar.txt
# svn add trunk/bar.txt
# svn ci -m "Created bar.txt"
# svn cp trunk/ /branches/branch1/
# svn ci -m "Created branch"
# svn cp trunk/ branches/branch2/
# svn ci -m "Created second branch"
# cd branches/
# echo "goodbye" > branch1/bar.txt
# svn mv branch2/bar.txt branch2/foo.txt
# cd branch2/
# svn ci -m "Moved bar.txt to foo.txt in branch2"
# cd ../branch1/
# svn ci -m "Fixed text in bar."
# cd ../../trunk/
# svn merge -r6:7 svn://loon/test/branches/branch2 .
D bar.txt
A foo.txt
# svn merge --dry-run -r5:8 svn://loon/test/branches/branch1 .
Skipped missing target: 'bar.txt'
And it's now difficult/impossible to get the updated text into
trunk/foo.txt. Without creating branches, at least you end up with an
unversioned copy of bar.txt when you do an update to pull in the renamed
file; having done the changes in branches, we're stuck.
Or am I missing something?
-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:44:49 2006