questions regarding svn metadata (.svn)

I'm trying to figure out a few things about the .svn
directories.  I 
can't seem to find much about them...I've searched around on
Google, SVN 
docs, Forums,  and Mailing Lists.  It's hard to search for
because I am 
not sure what keywords people use when talking about them. 
Searching 
for .svn is a bit useless...

So:

* have there ever been any discussions about using a
different style for 
storing the metadata - e.g. ala perforce - instead of .svn
files/dirs 
everywhere?  I don't want to start a new discussion on this
topic 
without having read any existing discourse

* are there any good sources for how to hide this
information from 
everyday unix tools like find and so on (I know how to use
various 
parameters, or | grep -v svn --- but I want something a bit
more 
automatic)?

Thanks!


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 8/26/07, Taylor Gautier <tgautierterracottatech.com> wrote:
> I'm trying to figure out a few things about the .svn
directories.  I
> can't seem to find much about them...I've searched
around on Google, SVN
> docs, Forums,  and Mailing Lists.  It's hard to search
for because I am
> not sure what keywords people use when talking about
them.  Searching
> for .svn is a bit useless...

It's called the Working Copy Administration Area, a.k.a.
Administrative Area.  The first place to search is the
svnbook which
you can find online.  You especially want to look here:
http://svnbook.red-bean.com/en/1.4/svn.developer.i
nsidewc.html first.

> So:
>
> * have there ever been any discussions about using a
different style for
> storing the metadata - e.g. ala perforce - instead of
.svn files/dirs
> everywhere?  I don't want to start a new discussion on
this topic
> without having read any existing discourse

I don't know about previous talks (though you can
browse/search this
mailing list archives), but svk deals with those
directories
differently.  It's worth having a look.

> * are there any good sources for how to hide this
information from
> everyday unix tools like find and so on (I know how to
use various
> parameters, or | grep -v svn --- but I want something a
bit more
> automatic)?

I use 'wcfind' sometime
(http://svn.collab.net/repos/svn/trunk/tools/client
-side/wcfind), a
find(1) wrapper using -prune option to hide .svn and CVS
dirs.

Cheers,
Charles

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On Aug 26, 2007, at 12:16 PM, Charles Acknin wrote:

> On 8/26/07, Taylor Gautier <tgautierterracottatech.com> wrote:
...
>> * have there ever been any discussions about using
a different  
>> style for
>> storing the metadata - e.g. ala perforce - instead
of .svn files/dirs
>> everywhere?  I don't want to start a new discussion
on this topic
>> without having read any existing discourse
>
> I don't know about previous talks (though you can
browse/search this
> mailing list archives), but svk deals with those
directories
> differently.  It's worth having a look.

We're planning to centralize all the administrative data for
a WC at  
the top of the WC, and provide a 'svn detach' command to
allow for  
severable sub-directories.  The WC data storage format will
probably  
change drastically when we do this, likely moving into
something like  
sqlite.  The information we track will likely be a superset
of what's  
tracked today in all the .svn dirs.

>> * are there any good sources for how to hide this
information from
>> everyday unix tools like find and so on (I know how
to use various
>> parameters, or | grep -v svn --- but I want
something a bit more
>> automatic)?
>
> I use 'wcfind' sometime
> (http://svn.collab.net/repos/svn/trunk/tools/client
-side/wcfind), a
> find(1) wrapper using -prune option to hide .svn and
CVS dirs.

I use wcgrep quite often.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

> -----Original Message-----
> From: Daniel Rall [mailto:dlrfinemaltcoding.com]
> Sent: Monday, August 27, 2007 1:43 PM
> To: Taylor Gautier
> Cc: Subversion Developers
> Subject: Re: questions regarding svn metadata (.svn)
> 
> We're planning to centralize all the administrative
data for a WC at
> the top of the WC, and provide a 'svn detach' command
to allow for
> severable sub-directories.  The WC data storage format
will probably
> change drastically when we do this, likely moving into
something like
> sqlite.  The information we track will likely be a
superset of what's
> tracked today in all the .svn dirs.

Daniel - is there an issue attached to that work, or has it
been
nominated for any particular release yet?  Maybe 1.6?

Eric


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On Tue, 28 Aug 2007, Miller, Eric wrote:

> > -----Original Message-----
> > From: Daniel Rall [mailto:dlrfinemaltcoding.com]
> > Sent: Monday, August 27, 2007 1:43 PM
> > To: Taylor Gautier
> > Cc: Subversion Developers
> > Subject: Re: questions regarding svn metadata
(.svn)
> > 
> > We're planning to centralize all the
administrative data for a WC at
> > the top of the WC, and provide a 'svn detach'
command to allow for
> > severable sub-directories.  The WC data storage
format will probably
> > change drastically when we do this, likely moving
into something like
> > sqlite.  The information we track will likely be a
superset of what's
> > tracked today in all the .svn dirs.
> 
> Daniel - is there an issue attached to that work, or
has it been
> nominated for any particular release yet?  Maybe 1.6?

Eric, I don't know of any associated issue in the tracker,
but you can
find a long discussion on the dev list:

 http://subversion.tigris.org/servlets
/ReadMsg?listName=dev&msgNo=123070

The feeling from that thread was that we'll probably try
this for 1.6.
Of course, this is an open source, volunteer-run project and
all that...