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
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.
--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:23:25 2006