On Oct 24, 2005, at 23:33, Michael Brian Bentley wrote:
> Just last week my group just decided to switch to SVN after eight
> lifetimes of using CVS, and I think we're already happier with svn
> than we have ever been with the veteran predecessor. It isn't all
> burly cheer, tho. Just this weekend one of our top developers was
> working on extensive changes to certain specific source files while
> another of our top developers was executing plan SABJEN-1 (we use
> project names from a current Ikea catalog), which involved moving
> our source tree down a directory level. When the first developer
> finished his changes and got it all to work, he updated.
>
> Now, I wasn't there when the first developer saw the results of his
> update attempt, but I do know from the resignedly scathing email
> that Something Had Gone Amiss And That We Were All Doomed, and I
> wrote some quick responses and dived into the svn web site looking
> for answers in the mailing list archives.
>
> There are several instances of "gee, we moved this file while
> someone was working on the source, and svn didn't work as expected
> when the work was returned." SVN evidently doesn't automatically
> track where files are moved to, effectively implementing a simple
> copy/delete. If it did, it would just do the right thing and handle
> the update by producing a properly merged file in the new location
> and providing the appropriate number of warning messages that the
> old files in the old locations are no longer terribly useful.
> Either that or just flat-out disallow operations until the file
> trees return to sensible condition.
>
> At any rate, svn's vaunted move and rename capabilities are now
> treated by our group as scary, requiring manual coordination
> between all developers before changes are done.
Hi. You're right that operations that restructure a project are not
very convenient to do when multiple people are working on a project.
As a concrete example of something that might happen in our company:
if you have this project:
/trunk/
htdocs/
css/
basic.css
img/
logo.png
And two developers have their own working copies of this tree, and
now they do different things:
Developer 1 creates a new directory web under trunk and moves htdocs
into it, and commits it.
Developer 2 edits basic.css and tries to commit it. Developer 2 will
get a message that he's out of date, and will have to update. When he
updates, the basic.css he was working on will be "deleted" and
readded under its new path web/htodcs/css/basic.css. But because he
had local changes to basic.css, it won't actually get deleted; it'll
get unversioned (svn status will show "?") and the developer will
have to manually reapply his changes to the file in its new location.
If we ever want to do a reorganization of all or part of a project,
we make sure no other developers are working on it at the time, and
that they then do an update before starting to work again. This will
not be very convenient given any particularly active project or any
particularly large number of developers, especially distributed ones.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 25 11:41:27 2005