I'm working on solving part of the rename problem in Subversion. A rename
problem is presented in the following scenario:
1.User A checks out /repos/trunk/proj containing foo.c
2.User B checks out /repos/trunk/proj containing foo.c
3.User A makes changes to foo.c
4.User B renames foo.c to bar.c and makes some changes
5.User B commits
6.User A updates
What happens is that foo.c is removed from version control and
bar.c is added, all updates done to foo.c by A are discarded and not
merged with the changes done by user B.
I have a design in mind that may solve this problem. This is actually a
part of my thesis where I have to develop some features for Subversion
that would suite the needs of the company I'm doing the thesis at. From
the beginning my assignment was to implement
since you guys are really doing a great job at that, i was advised to do
I got some ideas reading the design documents for merge-tracking that
might help solving the above mentioned problem. One idea
is to put complete rename history as a property in both the entries file
and at the server side so when merging, for every file that doesn't have a
match in repository (like foo.c and bar.c), i will try to find another
file and look in its rename history to find its match.
So for example, with the above scenario, bar would have the following
the name of the file it was copied from (path to foo.txt) , what revision
foo.txt had at that time.
If the file is renamed several times, it would have the following set of
information in the following manner:
a,b : c,d : e,f : ......
At the moment I'm trying to save this type of information and then i'll
try to extract it and see how I can use it. I noticed that there is rename
history in subversion (copyfrom_url, copyfrom_rev) but it is not
persistent at the client side. And as I understood from the design
document for merge-tracking, you don't want to contact the server more
than you do now, so extracting the information solely from the server side
might make it more busy.
I have never worked deeply with subversion prior to this, so I'm really
new to these kinds of big projects but I find it really exciting to work
with subversion since it is really well documented and well coded :)
What do you think guys? Is this design crazy? Please give any feedback,
and again, I hope I sent
this email to the right list because I know this email is sent to
thousands of users.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Oct 16 10:41:13 2007