Re: .svn directories (no doubt) revisited

If I'm in folder /work/wc/proja_trunk/src/com/fiddle/dee/d

and I do "svn update"

where does it look? How does svn know which of the parent folders is
the one with the svn data without opening each folder and listing the
contents to discover where the svn data is.

There are solutions for this of course. You could have the client
have a standard location within which it keeps stores of data for each
working copy but...

You give up the ability to treat each folder of a working copy as an
enclosed working copy... You would no longer just be able to locally
clone a working copy or trim it down. What I'm saying (and what I'm
hearing from others) is that there is no simple solution that resolves
this issue without giving up a lot of existing functionality.

--
Talden
On 17/11/06, Brad Cox, Ph.D. <bcox@virtualschool.edu> wrote:
> Surely such bright fellows could find a bulletproof alternative? Like
> instead of open("./.svn"), open($DIR), where $DIR is redefined
> in each subdir as ../../..(however many)/root.svn. It'd might tricky
> getting all the corner cases, but it just doesn't seem that hard.
>
> Ryan Schmidt wrote:
> > On Nov 16, 2006, at 13:36, Talden wrote:
> >
> >> On 17/11/06, Tim Hill wrote:
> >>
> >>> 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).
> >
> > Right. And that would seem to be a performance hit for using a working
> > copy. Instead of Subversion looking in one known place (the .svn
> > directory in the current directory), it has to look in potentially all
> > parent directories to discover whether the thing even is a working copy.
> >
> >
> >> imagine how easy converting the working copy to an export would be.
> >
> > True: currently, an export is a bit of work for the system, searching
> > the entire directory tree for the .svn directories. But making an export
> > is, I think, in general, an infrequent operation, while using a working
> > copy is a frequent operation. I'd prefer that frequent operations be
> > fast, at the expense of infrequent operations being slow, not vice-versa.
> >
> >
> > ---------------------------------------------------------------------
> > 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