Hello!
I'm curious: Is it somehow possible, to "reconstruct" a Subversion
repository, if all you have is a checked out directory? I mean, does
such a check out hold enough information reg. who did what and
when in the past? Does it also hold information about what (ie. diffs)
has changed?
Best re
> Hello!
>
> I'm curious: Is it somehow possible, to "reconstruct" a Subversion
> repository, if all you have is a checked out directory? I mean, does
> such a check out hold enough information reg. who did what and
> when in the past? Does it also hold information about what (ie. diffs)
> has cha
Short answer: no.
> -Original Message-
> From: a.sk...@gmail.com [mailto:a.sk...@gmail.com] On Behalf
> Of Alexander Skwar
> Sent: 03 August 2010 07:59
> To: users@subversion.apache.org
> Subject: Reconstruct repository from checkouts?
>
> Hello!
>
> I'm curious: Is it somehow possible
I don't recall exactly where I found this file (author's own site, I
think), but this works for me on CentOS 5.3; If the attachment doesn't
come through, ask and I'll email directly. Ah, here's where I got it:
http://www.szakmeister.net/fsfsverify/
Download link is at the bottom.
Tony.
> ---
Hello,
I have a question concerning intra-branch merging that someone may be
able to help me with. I'll explain what I was trying to do:
I had a trunk, and two branches from that trunk, b1 and b2. Work was
occurring simultaneously on b1 and b2, and I needed a new component that
had been crea
* Les Mikesell:
>> When I speak of a filesystem snapshot, I mean an instantaneous copy
>> of the volume (ala NetApp, EMC, ZFS). In this case, there is a
>> guarantee that if we snap the new "current", then we will also have
>> the other files (assuming that they have been flushed, etc, by the
>>
On Tue, Aug 03, 2010 at 10:33:28AM +, Florian Weimer wrote:
> Kernel-level buffers are taken into account. Application buffers
> aren't, the application has to take care of that. But if the
> Subversion fails to do that, it cannot recover from file system
> crashes, either, which is arguably
On Tue, Aug 3, 2010 at 6:56 AM, Stefan Sperling wrote:
> On Tue, Aug 03, 2010 at 10:33:28AM +, Florian Weimer wrote:
>> Kernel-level buffers are taken into account. Application buffers
>> aren't, the application has to take care of that. But if the
>> Subversion fails to do that, it cannot r
On 2010-08-02 14:41:29 -0400, Vallon, Justin wrote:
> That is the situation I raised. If the network connection between
> the host that is modifying the repository and the filesystem that
> houses the repository is lost, will be repository be (a) corrupt,
> (b) require cleanup (locks, etc), (c) pri
On 2010-08-02 18:09:26 -0400, Vallon, Justin wrote:
> If the client or server filesystem buffers are dirty, then the
> application has not flushed the data.
There can be a flush at the application level (e.g. fflush() function
in C), but this doesn't mean that the flush is also done at the
file sy
On 2010-08-03 12:56:28 +0200, Stefan Sperling wrote:
> On Tue, Aug 03, 2010 at 10:33:28AM +, Florian Weimer wrote:
> > Kernel-level buffers are taken into account. Application buffers
> > aren't, the application has to take care of that. But if the
> > Subversion fails to do that, it cannot r
Vincent Lefevre wrote:
On 2010-08-03 12:56:28 +0200, Stefan Sperling wrote:
On Tue, Aug 03, 2010 at 10:33:28AM +, Florian Weimer wrote:
Kernel-level buffers are taken into account. Application buffers
aren't, the application has to take care of that. But if the
Subversion fails to do that
Nico Kadel-Garcia wrote:
On Tue, Aug 3, 2010 at 6:56 AM, Stefan Sperling wrote:
On Tue, Aug 03, 2010 at 10:33:28AM +, Florian Weimer wrote:
Kernel-level buffers are taken into account. Application buffers
aren't, the application has to take care of that. But if the
Subversion fails to do
On Tue, Aug 03, 2010 at 02:36:41PM +0200, Vincent Lefevre wrote:
> On 2010-08-03 12:56:28 +0200, Stefan Sperling wrote:
> > On Tue, Aug 03, 2010 at 10:33:28AM +, Florian Weimer wrote:
> > > Kernel-level buffers are taken into account. Application buffers
> > > aren't, the application has to ta
Nico Kadel-Garcia wrote:
>> $ export `gnome-keyring-daemon`
>
> Good, but ouch. Let's try adding a bit of rigor, shall we? First,
> before running such a daemon, always check that it actually exists,
> where you expect it to exist. Running random commands that will handle
> passwords which may ha
Justin Georgeson wrote on Mon, Aug 02, 2010 at 17:39:49 -0500:
> I have a repo with >39k revisions. Last week, r39245 was committed, a merge
> of a single file from trunk to branch. It is the HEAD revision of that file
> on that branch. Turns out this revision is corrupt
>
> [svnad...@hourdcm3 ~
Same error.
-Original Message-
From: Tony Sweeney [mailto:tswee...@omnifone.com]
Sent: Tuesday, August 03, 2010 4:16 AM
To: Justin Georgeson; Mark Phippard
Cc: users@subversion.apache.org
Subject: RE: corrupt revision, "Reading one svndiff window read beyond the end
of the representation
Regarding reproducibility, that's what I was going for with #3. I found another
thread, http://svn.haxx.se/users/archive-2009-06/0723.shtml, concluding this
error is due to fsfsverify not being current with the latest format, so I'll
give the svndump to new repo and redo revision in new repo a t
Justin Georgeson wrote on Tue, Aug 03, 2010 at 10:03:21 -0500:
> Regarding reproducibility, that's what I was going for with #3. I found
> another thread, http://svn.haxx.se/users/archive-2009-06/0723.shtml,
> concluding this error is due to fsfsverify not being current with the latest
> format, so
(c) is an automatic hands-off recovery, either by just having the recovery
logic know how to clean up (delete stale files) or making the recovery logic
transparent (overwrite files). This would be possible where locks are managed
by the kernel/filesystem which "knows" when a process dies, and c
> From: Les Mikesell [mailto:lesmikes...@gmail.com]
>
> A filesystem snapshot should present exactly the same scenario as a machine
> that
> lost power or crashed for some similar reason at that moment, so the question
> boils down to whether subversion can recover sensibly from a crash at any
On 2010-08-03 08:03:33 -0500, Les Mikesell wrote:
> A filesystem snapshot should present exactly the same scenario as a
> machine that lost power or crashed for some similar reason at that
> moment, so the question boils down to whether subversion can recover
> sensibly from a crash at any point.
The new test repo up to r39244 was created and the merge was successfully
committed. Checking the rev file in that new repo it looks ok. But when I put
the new rev file into an existing repo it is still corrupt, although for
different reasons now. I tried fsfsverify.py on this new rev file just
On 2010-08-03 15:12:19 +0200, Stefan Sperling wrote:
> On Tue, Aug 03, 2010 at 02:36:41PM +0200, Vincent Lefevre wrote:
> > On 2010-08-03 12:56:28 +0200, Stefan Sperling wrote:
> > > Subversion carefully flushes file buffers after writing revision files.
> >
> > What do you mean by "flushes file b
After a series of changing the node-revision and checksum errors I now have a
revision file in the backup repo that I verifies and I can checkout head of
that branch and do a diff on that revision. However, I can't do a log on that
revision yet
[svnad...@hourdcm1 input]$ svn log -r 39245
svn: C
Think I have it fixed now. In case this is helpful to anyone else, here's the
final set of diffs from the original corrupt rev file and the now working copy.
Thanks for the help!
[svnad...@hourdcm1 ~]$ diff cm3-39245 39245
20c20
< text: 39008 0 820 34402 b0823a9c03c803b37b5adc33430cc796
f310eb9
Justin Georgeson wrote on Tue, Aug 03, 2010 at 13:37:22 -0500:
> The new test repo up to r39244 was created and the merge was successfully
> committed. Checking the rev file in that new repo it looks ok. But when I put
> the new rev file into an existing repo it is still corrupt, although for
>
Thanks a lot to all who replied! Answered my question.
Cheers,
Alexander
2010/8/3 Tony Sweeney
> Short answer: no.
>
> > -Original Message-
> > From: a.sk...@gmail.com [mailto:a.sk...@gmail.com] On Behalf
> > Of Alexander Skwar
> > Sent: 03 August 2010 07:59
> > To: users@subversion.apa
28 matches
Mail list logo
