John Kristian wrote:
> `svn move` is relatively harmful for this use case, because the implied
> `svn delete` causes subsequent updates to do relatively harmful things
> (such as delete working copies, and forget uncommitted additions and
> deletions).
I have to say, I don't understand this whole thread. It sounds like
you're inventing some fantastical problem that just doesn't exist. It
sounds like you're *anticipating* a problem, when it's just no big deal.
Say I have a working copy of /branches/foobranch. Then you come along
and rename the thing to /branches/barbranch.
When I run 'svn up' in my working copy, it *will not* be destroyed. An
update cannot destroy the entire working copy. Instead, I'll get a
semi-cryptic error message about 'unable to replace a directory from
within'. (Yes, it should be a better error message.)
At that point, I email you, or phone you, or turn to my neighbor and ask
what's up. The answer I get back is, "hey, didn't you read the
announcement? The branch moved to 'barbranch'. Just run 'svn switch'
to the new URL." So I do so.
There's no crisis here. No lost work. No need to "enforce" anything at
the server. And honestly, it's not svn's job to send announcements
about things being renamed. All you need to do is set up reasonable
out-of-bounds communication channels in your group. For example,
sending out commit emails that clearly show the rename happening. Or
send an announcement. Regardless, when updates stop working, people
will notice.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 11 05:29:01 2005