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.
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.
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.
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.
-- 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
Received on Fri Nov 17 00:56:05 2006