Hello guys!
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
merge-tracking(http://www.afconsult.com/templates/Page____40635.asp) but
since you guys are really doing a great job at that, i was advised to do
something else.
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
information:
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.
Yours,
Freddie Albertsman
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 16 10:41:13 2007