[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: .svn directories (no doubt) revisited

From: Talden <talden_at_gmail.com>
Date: 2006-11-16 20:36:45 CET

On 16 Nov 2006, at 13:17, Brad Cox, Ph.D. wrote:
> > I just joined this list to see what current thinking is on adopting
> > some alternative to hiding .svn directories in each directory. I
> > checked the archives since I'm sure this must have come up before
> > but found nothing.
> >
> > Hiding these directories in ./.svn breaks lots of thing that I rely
> > on heavily. In vim, I habitually use :e `grep -rl searchString .`
> > to find files containing searchString. But this picks up hits
> > in .svn directories, often lots of them, and if you accidentally
> > change one, it breaks that workarea. Hiding them elsewhere, like ../
> > foldername.svn instead of ./.svn, would avoid this landmine. Yes; I
> > know about | grep -v \.svn/.
> >
> > On MacOSX, iWork's Pages word processor and Keynote presentation
> > package both use folders to package the various pieces of a
> > document (xml, text, graphics, etc). An excellent alternative to
> > proprietary binary file formats. But you can't use them do document
> > software projects because subversion inserts its stuff (.svn
> > directories) inside them, which pages and keynote automatically
> > delete. I've filed an Apple bug, but expect they'll claim its not
> > their fault that bad things happen when other apps insert arbitrary
> > stuff inside iWork folders.

On 17/11/06, Tim Hill <drtimhill@comcast.net> wrote:
> I'm afraid there isn't much chance of a change here, but I'm with you
> on the whole .svn thing, since I too bump up against this when
> working on a Mac. I'm putting together a helper script to make
> working with OS X bundles/packages less painful, 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 Thu Nov 16 20:37:35 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.