Dear Ingo, dear Ben,
thanks for your replies!
It seems that there was no way for me to prevent the problem from happening
apart from keepin my whole team from working on the sources. As we just
migrated from CVS to subversion this is a very hard lesson to learn as these
kind of restructurization mechanisms where one of the reasons why I decided
to switch to subversion. I think I will have a hard time explaining the
problem to the sceptics in my team, that constantly claim that subversion is
still not in a stable state (comparable to CVS)...
But I am pleased that there are efforts to overcome this and to implement a
real "move". Until this is done, I want to ask you again, if you think that
using a branch/merge mechanism would have reduced the work I had to do after
the conflict arose?
Best,
Patrick
On Friday 22 April 2005 22:05, Ben Collins-Sussman wrote:
> On Apr 22, 2005, at 2:37 PM, Ingo Adler wrote:
> > When "true renames" are implemented - what's the situation of the
> > second committer? Wouldn't he have conflicts anyway or would you
> > silently merge the changes in the new destination? What about deletes?
>
> It means that when you run 'svn up', the server actually sends a "move"
> command, not "delete & add" commands. So if your file is locally
> edited, it gets moved, and now the file is still locally edited under
> the new name.
>
> But you're right, this still doesn't solve the "update tries to delete
> my edited file" problem. The fact that your edited file becomes
> unversioned can really be a shock to a coder -- it's too easy not to
> notice that it happens.
>
> The real reason we've not yet done the "tree conflict" solution is
> because it gets very complex once you start talking about directories.
> For example, what if the update tries to delete some parent directory
> of your edited file? Do we set the whole directory into a state of
> conflict? How far can the update run before bailing out? Our 1.0
> solution was to bail completely on the problem and just "make
> everything unversioned." But you're right, I think it's time to do
> better.
>
> kfogel and I have discussed this for the last 30 mins now, and we're
> definitely going to file an issue on this. As ghudson says, "we
> shouldn't let the perfect be the enemy of the good." We can certainly
> solve a chunk of the problem by marking individual files as
> (C)onflicted. It will take a bit of design work.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
--
Dipl.-Technoinform. Patrick Heinemann
Universitaet Tuebingen, WSI - RA, Sand 1, D-72076 Tuebingen, Germany
Phone: ( +49 / 0 ) 70 71 / 29 - 78 989 Fax: ( +49 / 0 ) 70 71 / 29 - 50 91
mailto:heinemann@informatik.uni-tuebingen.de
http://www-ra.informatik.uni-tuebingen.de
Attempto Tübingen - Robot Soccer Team
http://www-ra.informatik.uni-tuebingen.de/forschung/robocup/welcome_e.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 25 10:58:28 2005