I plan to cut 1.8.6, 1.7.15 and 1.9.0-alpha1 on Tuesday January 28th. Please
vote for changes in STATUS. In the case of 1.9.0-alpha1 reviewing CHANGES
would be greatly appreciated.
On Wed, Jan 22, 2014 at 10:19 PM, Philip Martin wrote:
> On IRC today we were discussing the validation code in
> svn_fs_fs__set_rep_reference. When inserting a row into the rep-cache
> the insert can fail because the row already exists. The usual way this
> would happen is that two parallel com
On Thu, Jan 23, 2014 at 11:00 AM, Evgeny Kotkov wrote:
> Hi,
>
> I've noticed that svnadmin recover and hotcopy commands are broken for old
> repositories around trunk@1560210. The problem can be reproduced by
> creating
> a new --compatible-version=1.3 / 1.2 / 1.1 FSFS repository, doing somethi
On 23.01.2014 17:18, stef...@apache.org wrote:
> Author: stefan2
> Date: Thu Jan 23 16:18:05 2014
> New Revision: 1560723
>
> URL: http://svn.apache.org/r1560723
> Log:
> When hotcopying non-shared repositories, checkpoint the progress after
> every revision. This is not strictly necessary and add
Philip Martin writes:
> svnadmin create repo
> svn mkdir -mm file://`pwd`/repo/A
> svn co file://`pwd`/repo wc
> mv repo repo2
> svn relocate file://`pwd`/repo file://`pwd`/repo2 wc
> svn cp -rhead wc/A wc/X
> sqlite3 wc/.svn/wc.db "select local_relpath, repos_id from nodes"
> |2
> A|2
> X|1
>
>
Branko Čibej writes:
> After relocating the working copy and performing a local copy, "svn
> info" crashes. I tested this with both trunk and 1.8.5, on OSX. I
> haven't had time to try to track this down yet.
A shorter recipe:
svnadmin create repo
svn mkdir -mm file://`pwd`/repo/A
svn co file:/
Hi all,
One of the repositories I am working with has a long list of "svn:external"
links. This has a major impact on working copy update performance, since
each external link needs an additional roundtrip to the (painfully slow) SVN
server. So it can easily be the case that the update of the main
After relocating the working copy and performing a local copy, "svn
info" crashes. I tested this with both trunk and 1.8.5, on OSX. I
haven't had time to try to track this down yet.
See the attached reproduction script and output.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // No
> -Original Message-
> From: Evgeny Kotkov [mailto:evgeny.kot...@visualsvn.com]
> Sent: donderdag 23 januari 2014 11:00
> To: dev@subversion.apache.org
> Subject: [RFC/PATCH] svnadmin: recover/hotcopy erroring out for old FSFS
> repositories
> If this might help to understand what is g
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: donderdag 23 januari 2014 11:55
> To: Julian Foad
> Cc: Philip Martin; dev@subversion.apache.org
> Subject: Re: FSFS rep-cache validation
>
> Julian Foad writes:
>
> > I get the problem. By "store it
Julian Foad writes:
> I get the problem. By "store its own 'head' revision" I meant store
> the maximum value of any referenced revision number -- in other words,
> simply a substitute for having an index and querying the maximum value
> in the index. If we update this value correctly then it wou
Philip Martin wrote:
> Julian Foad writes:
>> Ugh -- the doc string says if REJECT_DUP is TRUE, "return an error if
>> there is an existing match for REP->CHECKSUM" but the implementation
>> does something else: return an error if an existing match points to a
>> different rep (that is, a dif
Hi,
I've noticed that svnadmin recover and hotcopy commands are broken for old
repositories around trunk@1560210. The problem can be reproduced by creating
a new --compatible-version=1.3 / 1.2 / 1.1 FSFS repository, doing something
simple with it (say, running svn mkdir or svn checkout / add file
Julian Foad writes:
> Ugh -- the doc string says if REJECT_DUP is TRUE, "return an error if
> there is an existing match for REP->CHECKSUM" but the implementation
> does something else: return an error if an existing match points to a
> different rep (that is, a different rev/index/size), but ret
Philip Martin wrote:
> On IRC today we were discussing the validation code in
> svn_fs_fs__set_rep_reference. When inserting a row into the rep-cache
> the insert can fail because the row already exists. The usual way this
> would happen is that two parallel commits add content with the
> same c
15 matches
Mail list logo