Steinar Bang wrote on Sun, May 22, 2011 at 00:41:14 +0200:
> > Steinar Bang :
>
> > Steinar Bang :
> >> I tried adding this to /svn/conf/authz:
>
> >> [/trunk/someprog]
> >> * =
>
> >> (everything else in the file are comments)
> [snip!]
> > So I uncommented this line in the sample svnse
> Steinar Bang :
> Steinar Bang :
>> I tried adding this to /svn/conf/authz:
>> [/trunk/someprog]
>> * =
>> (everything else in the file are comments)
[snip!]
> So I uncommented this line in the sample svnserve.conf:
> # authz-db = authz
> And then svnsync pulled the entire repo. Or at
> Steinar Bang :
> I tried adding this to /svn/conf/authz:
> [/trunk/someprog]
> * =
> (everything else in the file are comments)
> But both tools still break at revision 683, which is in the path
> /trunk/someprog/metamodeller.
[snip!]
> I was using the svn+ssh method to access the repo.
> Daniel Shahaf :
> Steinar Bang wrote on Sat, May 21, 2011 at 18:26:30 +0200:
[snip! svnsync and svnrdump]
>> .., it would have been nice if it was possible to tell these tools to
>> make a clone of a particular part of the repository into a new
>> repository (or a dumpfile for that matter).
svnsync,svnrdump use the svn_ra_* API, not the svn_client_* API.
You should be able to use either of them if you install authz on your
repository such that *any* paths touched in r683 are unreadable by the
user svnsync/svnrdump connect as.
Steinar Bang wrote on Sat, May 21, 2011 at 18:26:30 +0200
> Steinar Bang :
> I've been looking to see if there are any tools that can slurp out the
> history of a repository, using the svn client API. But all repository
> conversion seems to be based on "svnadmin dump". And "svnadmin dump"
> croaks on all revisions later than 682...:-/
svnsync and
> Stefan Sperling :
> Steinar, I'm sorry we can't help quickly here. At the moment I have no time
> to look at this further. I hope you have a good backup you can restore from.
No luck there I'm afraid.
I have backups, but either they are too old to be of interest, or they
are corrupted as w
On Wed, May 18, 2011 at 12:18:54PM +0200, Daniel Shahaf wrote:
> > There doesn't seem to be a duplicated block. The revision file itself seems
> > to be fine, expect that one of the lengths of the bad rev doesn't seem to
>
> Huh? Are you referring to the two 'length' attributes in the text: and
>
Stefan Sperling wrote on Wed, May 18, 2011 at 12:12:48 +0200:
> On Wed, May 18, 2011 at 10:53:13AM +0200, Daniel Shahaf wrote:
> > What came out of this thread? Is this one of the known corruption kinds?
>
> It doesn't seem to be known.
> It could be a flipped bits on the hard drive for all we kn
On Wed, May 18, 2011 at 10:53:13AM +0200, Daniel Shahaf wrote:
> What came out of this thread? Is this one of the known corruption kinds?
It doesn't seem to be known.
It could be a flipped bits on the hard drive for all we know.
> Is this is a case of a data block being written partially in one
[ CC += julianf ]
What came out of this thread? Is this one of the known corruption kinds?
Is this is a case of a data block being written partially in one place
and fully in another, or a case of a corrupt or truncated data block?
--
Daniel
(at hackathon room)
Steinar Bang wrote on Sat, May
On Sat, 14 May 2011 22:46 +0300, "Daniel Shahaf" wrote:
> You probably don't need to know anything at all about svndiff --- if previous
> instances of the bug are representative, then you're free to treat consider
> the svndiff stream an opaque binary data.
>
> That is, previously what happen
You probably don't need to know anything at all about svndiff --- if previous
instances of the bug are representative, then you're free to treat consider the
svndiff stream an opaque binary data.
That is, previously what happened is that fsfs wrote
A_1 A_2 B_1 B_2 C_1 C_1 C_2 D_1 D_2 E_1 E_2
O
> Steinar Bang :
> Steinar Bang :
> Stefan Sperling :
>>> Try to locate boundaries of representations, which look as follows:
>>> https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure
>>> A representation begins with a line containing either "PLAIN\n" or
> Steinar Bang :
> Steinar Bang :
>> Um... how do one determine the length of the sequence? You are using
>> 10 bytes I guess...?
> Never mind. It's from that structure description you posted.
Er sorry! Not you, but Stefan Sperling. I didn't look at the From
headers of the emails.
> Steinar Bang :
> Um... how do one determine the length of the sequence? You are using
> 10 bytes I guess...?
Never mind. It's from that structure description you posted.
I'll study that some more.
> Daniel Shahaf :
> No, you should be looking for the sequence of bytes starting at offset
> 1916. So, the bytes are:
> 53564e018c0c823d
> (for example, 'xxd -s 1916 -l 10 -ps' will tell you that)
Um... how do one determine the length of the sequence? You are using 10
bytes I guess...
> Steinar Bang :
> Stefan Sperling :
>> Try to locate boundaries of representations, which look as follows:
>> https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure
>>A representation begins with a line containing either "PLAIN\n" or
>>"DELTA\n" or "
Daniel Shahaf wrote on Sat, May 14, 2011 at 22:05:59 +0300:
> an svndiff1 stream
Documented in: ^/subversion/trunk/notes/svndiff
Steinar Bang wrote on Sat, May 14, 2011 at 20:37:42 +0200:
> > Daniel Shahaf :
>
> > No, you should be looking for the sequence of bytes starting at offset
> > 1916. So, the bytes are:
>
> > 53564e018c0c823d
>
> > (for example, 'xxd -s 1916 -l 10 -ps' will tell you that)
>
> Um... how
On Sat, 14 May 2011 21:10 +0300, "Daniel Shahaf" wrote:
>
>
> On Sat, 14 May 2011 19:54 +0200, "Steinar Bang" wrote:
> > > Stefan Sperling :
> >
> > > The script probably took a wrong guess.
> >
> > > Hopefully this is the known corruption problem with a duplicate block of
> > > data in
On Sat, 14 May 2011 19:54 +0200, "Steinar Bang" wrote:
> > Stefan Sperling :
>
> > The script probably took a wrong guess.
>
> > Hopefully this is the known corruption problem with a duplicate block of
> > data in the revision file.
>
> > Can you check if the original revision file (i.e.
> Stefan Sperling :
> The script probably took a wrong guess.
> Hopefully this is the known corruption problem with a duplicate block of
> data in the revision file.
> Can you check if the original revision file (i.e. not modified by
> fsfsverify.py) somewhere contains a data block which con
On Sat, May 14, 2011 at 10:58:12AM +0200, Steinar Bang wrote:
> Platform:
> debian 6.0.1 "squeeze",
> subversion 1.6.16dfsg-1+b1,
> fsfsverify.py from
> http://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side
> python 2.6.6-3+squeeze6
>
> (information about the repository at
24 matches
Mail list logo
