[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: .svn directories (no doubt) revisited

From: Duncan Murdoch <murdoch_at_stats.uwo.ca>
Date: 2006-11-17 02:54:28 CET

On 11/16/2006 8:22 PM, Tim Hill wrote:
> On Nov 16, 2006, at 4:50 PM, Duncan Murdoch wrote:
>
>> On 11/16/2006 6:55 PM, Tim Hill wrote:
>>> Actually, I think there are *fewer* problems with the
>>> "distinct" .svn tree:
>>> 1. A tool run in an arbitrary directory can just walk up the tree
>>> to the root until it finds a .svn folder. It then knows it's in
>>> a working copy.
>> This assumes that you've only used svn to make modifications. If
>> you used OS services to copy a subtree somewhere else, it wouldn't
>> be able to find its .svn info. That makes it a little more fragile
>> than the current scheme: someone could accidentally modify a
>> directory name, and have a lot of trouble committing changes within
>> that directory.
>
> Agreed. Tree moves/renames are slightly nastier. But, actually, how
> well does svn handle this at present? If I rename a folder today (not
> using svn mv, just plain old mv), how well does svn do?

Whoops, forgot to reply to this. As far as I know the following will
happen:

If you update the parent it will make a new copy under the old name.

If you go into the moved subdir, you can do updates and commits just as
well as ever. It doesn't care that you moved it.

Just ran a quick test, and it did appear to work that way.

Duncan Murdoch

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 17 02:55:06 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.