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.
> 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.
> 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.
> 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".
Duncan Murdoch
>
> -- Tim
>
>
>
> On Nov 16, 2006, at 11:36 AM, Talden wrote:
>
>> On 16 Nov 2006, at 13:17, Brad Cox, Ph.D. wrote:
>>> ainful, but it's only a hack
>>> work-around.
>>>
>>> imho, the svn team would have better with a single .svn folder tree
>>> off the root of the working copy, so that there were two independent
>>> but related trees. This would have avoided any number of problems
>>> with today's implementation.
>> At face value this seemed a reasonable option... Let's say it
>> worked as
>>
>> svn co .../dev/projA/trunk a_trunk
>>
>> and this produced
>>
>> a_trunk/
>> svn/
>> ...
>> wc/
>> src/
>> something/
>>
>> This sounds good initially but fairly clearly introduces a fairly
>> significant condition. the .svn handling for folder 'something' needs
>> to know that, rather than ./.svn/ it must look for svndata in
>> ../../../svn/... (or whatever the locative ends up being).
>>
>> That is, a sub-folder isn't a self-contained tree any more... This
>> might interfere with other simple working copy manipulations such as
>> ripping out a sub-folder and deleting the rest of the working copy.
>>
>> It's a shame such a simple schema is inconvenient in other ways...
>> imagine how easy converting the working copy to an export would be.
>>
>> --
>> Talden
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 17 01:50:49 2006