Re: Antwort: Re: Re: dangerous implementation of rep-sharing cache for fsfs

On 06/25/2010 03:34 PM, Daniel Shahaf wrote: [1] apparently, no SHA-1 collisions have been found to date. (see #svn-dev log today) We know SHA-1 collisions must exist, however - they are also likely to take unlikely form. The algorithms were specifically chosen so that small changes in b

Re: Stalish downloads still on Tigris

OK, I just updated the page to not have those links. On Fri, Jun 25, 2010 at 4:51 PM, Jack Repenning wrote: > On Jun 25, 2010, at 4:50 AM, Mark Phippard wrote: > >> Yes, that is what I meant.  Remove those two links.  I am not near a >> working copy, feel free to make the change. > > Yes, please

Re: Stalish downloads still on Tigris

On Jun 25, 2010, at 4:50 AM, Mark Phippard wrote: > Yes, that is what I meant. Remove those two links. I am not near a > working copy, feel free to make the change. Yes, please remove them (or remake them): I'm getting a lot of complaints to feedb...@tigris from people who used them and got er

Re: svn commit: r957094 - in /subversion/trunk: ./ subversion/include/ subversion/libsvn_client/ subversion/libsvn_fs*/ subversion/libsvn_ra*/ ...

C. Michael Pilato wrote: > Arfrever Frehtes Taifersar Arahesis wrote: >> I suggest to create libsvn_ra_util library (similar to libsvn_fs_util). >> The code of svn_ra_get_path_relative_to_root() would be moved to >> svn_ra__get_path_relative_to_root(), which would be defined in >> libsvn_ra_util.

Re: svn commit: r957094 - in /subversion/trunk: ./ subversion/include/ subversion/libsvn_client/ subversion/libsvn_fs*/ subversion/libsvn_ra*/ ...

Arfrever Frehtes Taifersar Arahesis wrote: > I suggest to create libsvn_ra_util library (similar to libsvn_fs_util). > The code of svn_ra_get_path_relative_to_root() would be moved to > svn_ra__get_path_relative_to_root(), which would be defined in libsvn_ra_util. > libsvn_ra and libsvn_ra_svn woul

Re: Ruby bindings don't work with 1.9 + patch

Sorry about that, I was in a rush to get it done and wasn't really paying attention. And yes, it should be back ported to the 1.6 branch. Joe Rozner On Jun 24, 2010, at 4:15 AM, Hyrum K. Wright wrote: > Applied in r957507. I noticed the patch was against 1.6.12, but it > applied cleanly to trun

Re: Antwort: Re: Re: dangerous implementation of rep-sharing cache for fsfs

Daniel Shahaf wrote: > Daniel Shahaf wrote on Fri, 25 Jun 2010 at 22:34 -: >> If you have specific questions about FSFS internals, you can ask them on >> this list. > > Why don't you just use BDB? Or use FSFS with rep-sharing disabled? BDB does rep-sharing, too, and doesn't allow you to disa

Re: Antwort: Re: Re: dangerous implementation of rep-sharing cache for fsfs

Daniel Shahaf wrote on Fri, 25 Jun 2010 at 22:34 -: > If you have specific questions about FSFS internals, you can ask them on > this list. Why don't you just use BDB? Or use FSFS with rep-sharing disabled?

RE: svn commit: r958007 - /subversion/trunk/subversion/libsvn_wc/node.c

You have to check added before checking have_base as an add will be added below its parent, but can still overlay a switched (base)node. Bert Huijben (mobile phone) - Oorspronkelijk bericht - Van: dan...@apache.org Verzonden: vrijdag 25 juni 2010 17:40 Aan: comm...@subversion.apache.org

Re: Antwort: Re: Re: dangerous implementation of rep-sharing cache for fsfs

michael.fe...@evonik.com wrote on Fri, 25 Jun 2010 at 19:33 -: > Hello, > > Martin got my point: > >> It's not the probability which concerns me, it's what happens when > >> a file collides. If I understood the current algorithm right the > >> new file will be silently replaced by an unrelated

Re: svn commit: r957751 - /subversion/site/publish/packages.html

Greg Stein wrote: > On Fri, Jun 25, 2010 at 14:31, Mark Phippard wrote: >> The distinction we make internally at CollabNet over when we use the >> term certified on our binaries is the process they go through before >> posting. >> >> ...explanation... > > Thanks for that explanation. It helps bel

Re: svn commit: r957921 - in /subversion/trunk/subversion: libsvn_wc/workqueue.c libsvn_wc/workqueue.h tests/libsvn_wc/pristine-store-test.c

On Fri, Jun 25, 2010 at 08:36, wrote: >... > +++ subversion/trunk/subversion/libsvn_wc/workqueue.c Fri Jun 25 12:36:53 2010 >... > +svn_error_t * > +svn_wc__wq_build_pristine_get_translated(svn_skel_t **work_item, > +                                         svn_wc__db_t *db, > +                  

Re: svn commit: r957905 - in /subversion/trunk/subversion: libsvn_subr/dirent_uri.c tests/libsvn_subr/dirent_uri-test.c

On Fri, Jun 25, 2010 at 08:02, wrote: > Author: rhuijben > Date: Fri Jun 25 12:02:49 2010 > New Revision: 957905 > > URL: http://svn.apache.org/viewvc?rev=957905&view=rev > Log: > In the dirent/uri code: Replace all checks for WIN32 or __CYGWIN__ > with a check for SVN_USE_DOS_PATHS and set this

Re: svn commit: r957751 - /subversion/site/publish/packages.html

On Fri, Jun 25, 2010 at 14:31, Mark Phippard wrote: > The distinction we make internally at CollabNet over when we use the > term certified on our binaries is the process they go through before > posting. > >...explanation... Thanks for that explanation. It helps below: >... > I was fine with yo

Re: Do SHA1 pristines need a wc format bump?

On Fri, Jun 25, 2010 at 14:21, Philip Martin wrote: > Greg Stein writes: > >> If in-db props are needed for pristine, then I don't think swapping >> their format numbers makes sense. > > No, in-db-props are not needed for pristine. Oh! For some reason, I thought it did. If you're ready to go, t

Re: svn commit: r957751 - /subversion/site/publish/packages.html

The distinction we make internally at CollabNet over when we use the term certified on our binaries is the process they go through before posting. Our certified binaries go through a cross-functional release process before they are posted. Release engineering builds the binaries does the Subversi

Re: Do SHA1 pristines need a wc format bump?

Greg Stein writes: > If in-db props are needed for pristine, then I don't think swapping > their format numbers makes sense. No, in-db-props are not needed for pristine. -- Philip

Re: Do SHA1 pristines need a wc format bump?

If in-db props are needed for pristine, then I don't think swapping their format numbers makes sense. My only delay in performing the bump for in-db props is testing the upgrade code. We can cross our fingers, do the bump, and post-bump complete the upgrade testing. (the exposure would only be lim

Do SHA1 pristines need a wc format bump?

Compiling with SVN_EXPERIMENTAL_PRISTINE causes pristine text to be stored in .svn/pristine/ using SHA1 filenames instead of .svn/text-base/ using filenames derived from the working file. It's nearly complete enough to pass the regression test, I'm down to 4 FAILs at present. I've reached the sta

Re: svn commit: r957751 - /subversion/site/publish/packages.html

What does "certified" mean at all? That sounds like some kind of certifying authority exists, which is not the case. The binaries are built and supported by these various companies. "self-certify" is kind of an oxymoron in my book. I'm certainly open to re-phrasing by the companies with these bina

Re: Stalish downloads still on Tigris

On Fri, Jun 25, 2010 at 12:31 PM, Geoff Rowell wrote: >> As Hyrum indicated there has never been an "official" location, and we >> are not talking about deleting the archive, just making it more clear >> that it is old and there are newer versions available. >> >> If there are things like the Pyt

Antwort: Re: Re: dangerous implementation of rep-sharing cache for fsfs

Hello, Martin got my point: >> It's not the probability which concerns me, it's what happens when a file collides. If I understood the current algorithm right the new file will be silently replaced by an unrelated one and there will be no error and no warning at all. If it's some kind of mach

Re: Stalish downloads still on Tigris

On Fri, Jun 25, 2010 at 8:33 AM, Mark Phippard wrote: > On Fri, Jun 25, 2010 at 7:29 AM, Christian Boos wrote: > >> As far as I can tell, among the different places listed in >> http://subversion.apache.org/packages.html#windows Tigris.org was the only >> place to provide direct access to the svn

Re: Antwort: Re: dangerous implementation of rep-sharing cache for fsfs

On Fri, 2010-06-25 at 08:45 -0400, michael.fe...@evonik.com wrote: > I am actually more interested in finding reliable solution > instead of discussing mathematics and probabilities. The discussion of probabilities affects whether it would be justifiable to change Subversion to address hash colli

Re: dangerous implementation of rep-sharing cache for fsfs and libsvn_wc

By the way, wc-ng (in Subversion 1.7) will use sha1's for storing pristine texts too. (It will checksum the same contents that fsfs checksums, but currently it doesn't compare filesizes.) So the risk of sha1 collisions (as theoretical or not as it may be) will apply to working copies, too, no

Re: Re: dangerous implementation of rep-sharing cache for fsfs

On Fri, 25 Jun 2010, Mark Phippard wrote: On Fri, Jun 25, 2010 at 8:45 AM, wrote: 4. you under estimate the error done by misusing math. methods.   As I already said in my first e-mail. SHA-1 is developed   to detected random and willful data manipulation.   It's a cryptographic hash, so t

Re: dangerous implementation of rep-sharing cache for fsfs

Mark Mielke wrote on Fri, 25 Jun 2010 at 17:15 -: > There are many widely used systems that rely on statistical improbability. Public-key encryption is another example. (You always assume that if someone else runs 'gpg --gen-key' they won't get *your* secret key by chance.) > Michael: Feel f

Re: dangerous implementation of rep-sharing cache for fsfs

The rep sharing collisions, even if possible due to collisions around the world (has this happened in practice?), still have no effect on the single repository which does not experience the collision. There are many widely used systems that rely on statistical improbability. Disk drive hardwar

Re: svn commit: r957901 - /subversion/trunk/subversion/libsvn_subr/dirent_uri.c

hwri...@apache.org wrote: > Author: hwright > Date: Fri Jun 25 11:52:02 2010 > New Revision: 957901 > > URL: http://svn.apache.org/viewvc?rev=957901&view=rev > Log: > * subversion/libsvn_subr/dirent_uri.c > (svn_uri_et_dirent_from_file_url): Fix compilation errors introduced in ^

Re: Re: dangerous implementation of rep-sharing cache for fsfs

On Fri, Jun 25, 2010 at 1:45 PM, wrote: > Hello, > > I am actually more interested in finding reliable solution > instead of discussing mathematics and probabilities. You can just disable rep-sharing. You won't have the space savings, but you'll feel better inside, knowing that the near-zero pr

Re: Stalish downloads still on Tigris

On Fri, Jun 25, 2010 at 1:33 PM, Mark Phippard wrote: > On Fri, Jun 25, 2010 at 7:29 AM, Christian Boos wrote: > >> As far as I can tell, among the different places listed in >> http://subversion.apache.org/packages.html#windows Tigris.org was the only >> place to provide direct access to the svn

Re: Re: dangerous implementation of rep-sharing cache for fsfs

On Fri, Jun 25, 2010 at 8:45 AM, wrote: > 4. you under estimate the error done by misusing math. methods. > >   As I already said in my first e-mail. SHA-1 is developed >   to detected random and willful data manipulation. >   It's a cryptographic hash, so that there is a low chance of >   guessi

Antwort: Re: dangerous implementation of rep-sharing cache for fsfs

Hello, I am actually more interested in finding reliable solution instead of discussing mathematics and probabilities. But to make it short, you are wrong! 1. You are comparing apples and oranges. A corruption due to faulty hardware, is a random error, because it's not inherent to metho

Re: Stalish downloads still on Tigris

On Fri, Jun 25, 2010 at 7:29 AM, Christian Boos wrote: > As far as I can tell, among the different places listed in > http://subversion.apache.org/packages.html#windows Tigris.org was the only > place to provide direct access to the svn-python bindings (e.g. > svn-python-1.6.6.win32-py2.[56].exe)

RE: [Patch] - Fix paths on OS/2 - patch for trunk - svn-paths-trunk.diff [1/1]

Bert Huijben wrote: > > -Original Message- > > From: Paul Smedley [mailto:pauldes...@despamsmedley.id.au] > > > > [[[ > > Fix paths & command prompts for OS/2 by re-using WIN32 #ifdef's > > > > * subversion/libsvn_subr/dirent_uri.c > > * subversion/libsvn_subr/io.c > > * subversion/libsvn

RE: [Patch] - Fix paths on OS/2 - patch for trunk - svn-paths-trunk.diff [1/1]

> -Original Message- > From: Paul Smedley [mailto:pauldes...@despamsmedley.id.au] > Sent: vrijdag 25 juni 2010 6:28 > To: dev@subversion.apache.org > Subject: Re: [Patch] - Fix paths on OS/2 - patch for trunk - svn-paths- > trunk.diff [1/1] > > Hi All, > > This patch is for trunk: > >

Re: Stalish downloads still on Tigris

On Fri, Jun 25, 2010 at 12:29 PM, Christian Boos wrote: > Hello, > > On 6/25/2010 1:09 PM, Mark Phippard wrote: >> >> Given that they are out of date and no longer maintained maybe we >> should start by removing them from our current list of binary packages >> and see if the traffic for them goes

Re: Stalish downloads still on Tigris

On Fri, Jun 25, 2010 at 7:27 AM, Julian Foad wrote: > Mark Phippard wrote: >> Given that they are out of date and no longer maintained maybe we >> should start by removing them from our current list of binary packages > > You mean removing the two "Tigris.org" links from the "Windows" section > of

Re: Stalish downloads still on Tigris

Hello, On 6/25/2010 1:09 PM, Mark Phippard wrote: Given that they are out of date and no longer maintained maybe we should start by removing them from our current list of binary packages and see if the traffic for them goes down? I doubt that is where the traffic is coming from but it is worth

Re: Stalish downloads still on Tigris

Mark Phippard wrote: > Given that they are out of date and no longer maintained maybe we > should start by removing them from our current list of binary packages You mean removing the two "Tigris.org" links from the "Windows" section of ? Yes, +1. > an

Re: Stalish downloads still on Tigris

Given that they are out of date and no longer maintained maybe we should start by removing them from our current list of binary packages and see if the traffic for them goes down? I doubt that is where the traffic is coming from but it is worth a try and I think it also makes sense. Fellow SVN De

Re: svn commit: r957751 - /subversion/site/publish/packages.html

On Thu, 2010-06-24, gst...@apache.org wrote: > Author: gstein > Date: Thu Jun 24 23:40:44 2010 > New Revision: 957751 > > URL: http://svn.apache.org/viewvc?rev=957751&view=rev > Log: > The Subversion community does not "certify" any binaries. These particular > binaries have professional support b

Re: svn commit: r957855 - /subversion/trunk/subversion/libsvn_wc/util.c

phi...@apache.org wrote: > Author: philip > Date: Fri Jun 25 09:03:56 2010 > New Revision: 957855 > > URL: http://svn.apache.org/viewvc?rev=957855&view=rev > Log: > Fix a compiler warning. Looks like you fixed a bug, not just a warning! - Julian > * subversion/libsvn_wc/util.c > (svn_wc__sta

Re: [PATCH] Let "svn blame" truncate long author names to keep the column width fixed to 10 characters

Julian Foad wrote on Fri, 25 Jun 2010 at 13:19 -: > Done; committed in r957874, omitting the "blame -v" part. Beat me to it :-)

Re: [PATCH] Let "svn blame" truncate long author names to keep the column width fixed to 10 characters

Johan Corveleyn wrote: > On Thu, Jun 24, 2010 at 1:47 PM, Daniel Shahaf > wrote: > > You truncate the author name even in 'svn blame -v' --- is that per the > > previous thread's concensus too? (Personally I lean towards not > > truncating with -v.) > > Thanks for the feedback. > > I didn't co

Re: [Patch] OS/2 configuration changes - svn-config.diff [1/1]

"Paul Smedley" writes: > Index: subversion/include/svn_config.h > === > --- subversion/include/svn_config.h (revision 957722) > +++ subversion/include/svn_config.h (working copy) > @@ -138,8 +138,14 @@ > */ > #define SVN_CONFI

Re: [Patch] - Fix paths on OS/2 - svn-paths.diff [1/1]

On 25.06.2010 10:28, Daniel Shahaf wrote: > In the meantime I discovered that 'uudecode -p' extracts the attachments > from the /^begin/../^end/ lines. > > I learnt something new today... > > Daniel > (and it's not noon yet!) > Then it's time to continue your education and start sending shar fi

RE: [Patch] - Fix paths on OS/2 - svn-paths.diff [1/1]

> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: vrijdag 25 juni 2010 10:02 > To: Daniel Näslund > Cc: p...@smedley.id.au; dev@subversion.apache.org > Subject: Re: [Patch] - Fix paths on OS/2 - svn-paths.diff [1/1] > > Daniel Näslund wrote on Fri, 25 Ju

Re: [Patch] - Fix paths on OS/2 - svn-paths.diff [1/1]

In the meantime I discovered that 'uudecode -p' extracts the attachments from the /^begin/../^end/ lines. I learnt something new today... Daniel (and it's not noon yet!)

Re: [Patch] - Fix paths on OS/2 - svn-paths.diff [1/1]

Daniel Näslund wrote on Fri, 25 Jun 2010 at 07:46 -: > On Fri, Jun 25, 2010 at 02:03:17AM +, Paul Smedley wrote: > > [[[ > > Fix paths & command prompts for OS/2 by re-using WIN32 #ifdef's > > > > * subversion/libsvn_subr/dirent_uri.c > > * subversion/libsvn_subr/io.c > > * subversion/libs