Re: Efficiency of rep-sharing (deduplication) in 1.8 and later
Mark Phippard wrote on Fri, Sep 12, 2014 at 11:24:43 -0400: > On Fri, Sep 12, 2014 at 11:17 AM, Thomas Harold > wrote: > > > I have a question about how efficient SVN is at de-duplication within a > > repository with regards to files that appear in multiple locations, but > > which have the same content. > > > > I know a small improvement was made in 1.8... > > > > http://subversion.apache.org/docs/release-notes/1.8.html#fsfs-enhancements > > > > > When representation sharing has been enabled, Subversion 1.8 will now > > > be able to detect files and properties with identical contents within > > > the same revision and only store them once. This is a common > > > situation when you for instance import a non-incremental dump file or > > > when users apply the same change to multiple branches in a single > > > commit. > > > > #1 - If a commit puts files A, B and C into the repository, and a latter > > commit puts files B, C and D into the repository at a different > > location, is SVN smart enough to realize that B and C are already stored > > in the repository? > > > > In other words, does it track each individual file separately, even if > > they were all part of one big revision? > > > > Representation cache is based on the sha of the rep. So it does not matter > what the filename is or where it is stored. If it has the same sha as an > existing rep, then it will be be shared. > > The small improvement in 1.8 was simply to do this for files being added > within the same revision, but the other scenario was already supported. > > I think it is worth pointing out that a rep is not necessarily a "file". > It is the specific delta that SVN would be storing in the repository DB. The sha1 of the rep itself doesn't matter. The rep-cache.db file is a cache of (sha1 of fulltext ↦ location of rep generating that fulltext). As to the idea of doing the sha1 at chunk level rather than at file level: I suggest to discuss that on dev@. Some backend devs might otherwise miss the discussion. Cheers, Daniel
Re: List trouble - not received, how to get index ?
Kerry, Richard wrote on Thu, Dec 04, 2014 at 15:59:34 +: > Can anyone tell me how to get the index number from a message on this list ? > Just email users-help@ and the autoreply will tell you how to get a list of message numbers for use with the -get command. Or you could go to https://subversion.apache.org/mail/users/ and fetch the appropriate mbox file(s). Daniel
Re: svn status & external definitions
Daniel Becroft wrote on Tue, Dec 02, 2014 at 14:44:06 +1000: > Hi, > > On a fresh checkout from a repository, an 'svn status' will return the > following: > > X alpha > X beta\B > X beta\C > > These are the folders created by svn:externals properties. No problem here. > > However, using an 'svn status --ignore-externals' command does not change > the output - the external folders continue to be listed. > > The help text for this switch just says '--ignore-externals : ignore > externals definitions'. > > Is this intended behaviour? Not sure.. > If so, is what scenario will this switch do something? It prevents svn from recursing into the external: [[[ % svn st X A2 Performing status on external item at 'A2': A A2/D ]]] [[[ % svn st --ignore-externals X A2 ]]] Daniel
RE: svn status & external definitions
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: zaterdag 6 december 2014 12:28 > To: Daniel Becroft > Cc: subversion > Subject: Re: svn status & external definitions > > Daniel Becroft wrote on Tue, Dec 02, 2014 at 14:44:06 +1000: > > Hi, > > > > On a fresh checkout from a repository, an 'svn status' will return the > > following: > > > > X alpha > > X beta\B > > X beta\C > > > > These are the folders created by svn:externals properties. No problem here. > > > > However, using an 'svn status --ignore-externals' command does not change > > the output - the external folders continue to be listed. > > > > The help text for this switch just says '--ignore-externals : ignore > > externals definitions'. > > > > Is this intended behaviour? > > Not sure.. Are we looking at a file external or at a directory external? Bert
