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?
>
>>> 2. No problems with Mac OSX packages and other "opaque" folder
>>> schemes.
>>> 3. No problems with folder delete. At present, if you delete a
>>> folder (and the .svn hidden folder), svn loses any memory that
>>> the folder was there.
>> That's not true if it's a subfolder of a versioned folder. The
>> next update of the parent will restore it.
>
> Er .. yes. I wonder what I was thinking when I wrote that? I know I
> had something slightly different in mind. Oh well!
>>> 4. No "mixed" working copies. Nasty things happen if you use svn
>>> checkout to create a disjoint working copy within an existing
>>> working copy. The single .svn tree can handle this since the tool
>>> can determine the context of the entire tree.
>> What sort of nasty things? I've been doing that for a while
>> without obvious problems.
>
> Hmmm. What I found, after some testing, was this:
>
> svn co $REPO/foo -N
> svn co $REPO/foo/bar foo
>
> This does not yield the same result as:
>
> svn co $REPO/foo
I think this is a fairly well-known problem with -N. What I have is a
complete checkout of $REPO/foo, and within that, a checkout of bar from
a different repository completely. If I ask the status in foo, it tells
me that bar is unversioned, but within bar, everything works fine.
>
> If I recall (some time ago) the issue is that "foo" does not have any
> knowledge of "bar", so things like commits and updates don't behave
> as expected.
>
>>> 5. Ability to set persistent partial mappings. At present, its
>>> difficult to tell svn to permanently exclude parts of a folder
>>> tree since svn has nowhere to put this information (the .svn
>>> folder would have to be in a folder that doesn't exist!). This
>>> makes more complex mappings difficult.
>> No, the parent's .svn info could have a record saying "don't bother
>> with child foo, only do updates of bar".
>
> Doesn't work in the root.
Right, it doesn't currently work like that. But I think the fix for it
is orthogonal to the location of the .svn folder.
Duncan Murdoch
>
> --Tim
>
---------------------------------------------------------------------
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:32:37 2006