Bert Huijben wrote on Tue, Jul 31, 2012 at 22:11:31 +0200:
>
>
> > -Original Message-
> > From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
> > Philip Martin
> > Sent: dinsdag 31 juli 2012 21:30
> > To: Julian Foad
> > Cc: dev@subversion.apache.org
> > Subject: Re: FSFS v
On Tue, Jul 17, 2012 at 1:28 PM, Julian Foad wrote:
> There are some merge scenarios for which it's not clear whether the user
> should specify '--reintegrate' or not. We need to decide what the
> 'symmetric' (i.e. automatically-choosing) code should do in those cases.
>
> The following example
I (Julian Foad) wrote on 25 July 2012:
> I can't see the session URL semantics documented where I'm looking for
> it (in svn_ra.h). Would the following doc string update for ra_open4() be an
> improvement?
Committed in r1367794. This doesn't touch on the authz implications which is
the thing
> -Original Message-
> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
> Philip Martin
> Sent: dinsdag 31 juli 2012 21:30
> To: Julian Foad
> Cc: dev@subversion.apache.org
> Subject: Re: FSFS verifies rep-cache when disabled
>
> Julian Foad writes:
>
> > Philip Marti
Julian Foad writes:
> Philip Martin wrote:
>
>>& quot;svnadmin verify" verifies a rep-cache.db file even when
>> rep-caching is disabled. This appears to be intentional but I don't
>> understand the reasoning.
>>
>> svn_fs_fs__verify calls svn_fs_fs__exists_rep_cache to see if the
>> cache exis
Philip Martin wrote:
>& quot;svnadmin verify" verifies a rep-cache.db file even when rep-caching
> is
> disabled. This appears to be intentional but I don't understand the
> reasoning.
>
> svn_fs_fs__verify calls svn_fs_fs__exists_rep_cache to see if the cache
> exists and then calls svn_fs_fs_
I'm investigating a discrepancy that shows up, when 'symmetric merge' is
enabled [1], in the notifications printed by some merges. Merge_tests 78 fails
because the expected notification for the last merge is:
--- Merging r6 through r9 into 'H_COPY':
U H_COPY/psi
D H_COPY/nu
--- Recording
"svnadmin verify" verifies a rep-cache.db file even when rep-caching is
disabled. This appears to be intentional but I don't understand the
reasoning.
svn_fs_fs__verify calls svn_fs_fs__exists_rep_cache to see if the cache
exists and then calls svn_fs_fs__walk_rep_reference which has the
comment:
Daniel Shahaf writes:
> s...@tigris.org wrote on Tue, Jul 31, 2012 at 01:33:51 -0700:
>> With Daniel's fix for #4129, this will cause a verification error: If
>> a root nodes' (rN) predecessor (rN-1) has the flag set, it will not
>> report its revision (N-1) but it's respective predecessor's revi
Hi,
A "svn move" of a directory containing some externals seems to somehow corrupt
the externals:
m.schaber@SchaberMNB /cygdrive/d/test/externals/wc
$ svn status -v
66 m.schaber.
65 m.schaberfoo
Xfo
s...@tigris.org wrote on Tue, Jul 31, 2012 at 01:33:51 -0700:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4031
>
>
>
> User sf changed the following:
>
> What|Old value |New value
> ===
Stefan Fuhrmann wrote on Tue, Jul 31, 2012 at 10:56:18 +0200:
> On Tue, Jul 31, 2012 at 10:45 AM, Daniel Shahaf wrote:
>
> > Stefan Fuhrmann wrote on Tue, Jul 31, 2012 at 10:35:24 +0200:
> > > On Thu, Jul 26, 2012 at 11:41 AM, Philip Martin
> > > wrote:
> > >
> > > > Stefan Fuhrmann writes:
> >
Stefan Fuhrmann writes:
> On Mon, Jul 30, 2012 at 12:40 PM, Philip Martin
> wrote:
>
>> When the commit process finds a representation in the rep-cache the only
>> sanity check that happens is that the revision must be less than or
>> equal to HEAD. We don't check that the offset is valid:
>>
>>
Philip Martin writes:
> When the commit process finds a representation in the rep-cache the only
> sanity check that happens is that the revision must be less than or
> equal to HEAD.
This check is a bit worrying. The check is supposed to handle the case
where the rep-cache is newer than the re
On Tue, Jul 31, 2012 at 10:45 AM, Daniel Shahaf wrote:
> Stefan Fuhrmann wrote on Tue, Jul 31, 2012 at 10:35:24 +0200:
> > On Thu, Jul 26, 2012 at 11:41 AM, Philip Martin
> > wrote:
> >
> > > Stefan Fuhrmann writes:
> > >
> > > > Yesterday, I debugged the code and found out why r(N-2)
> > > > wo
On Mon, Jul 30, 2012 at 12:40 PM, Philip Martin
wrote:
> When the commit process finds a representation in the rep-cache the only
> sanity check that happens is that the revision must be less than or
> equal to HEAD. We don't check that the offset is valid:
>
> echo foo > foo
> svnadmin create
Stefan Fuhrmann wrote on Tue, Jul 31, 2012 at 10:35:24 +0200:
> On Thu, Jul 26, 2012 at 11:41 AM, Philip Martin
> wrote:
>
> > Stefan Fuhrmann writes:
> >
> > > Yesterday, I debugged the code and found out why r(N-2)
> > > would be reported. This was due to is-fresh-txn-root
> > > being set on so
On Thu, Jul 26, 2012 at 11:41 AM, Philip Martin
wrote:
> Stefan Fuhrmann writes:
>
> > Yesterday, I debugged the code and found out why r(N-2)
> > would be reported. This was due to is-fresh-txn-root
> > being set on some of the root noderevs. Some of the
> > affected repositories don't use direc
On Mon, Jul 30, 2012 at 6:47 PM, Philip Martin
wrote:
> When writing an FSFS revision file some parts are written in hash order
> and so with a recent APR the order is not predictable. Thus loading the
> same dumpfile into two separate empty repositories produces different
> revision files. The
19 matches
Mail list logo
