On Wed, 13 Dec 2017 17:23:16 -0500, Nico Kadel-Garcia
wrote:
>> cvs2svn was executed on Ubuntu. The dump file was gzipped and then
>> moved via FTP *to* Windows.
>
>FTP can manipulate line endings, depending on its settings.
That is one reason why I compressed the file (gzip)
On Wed, Dec 13, 2017 at 11:31 AM, Bo Berglund wrote:
> On Wed, 13 Dec 2017 17:22:48 +0100, Stefan Sperling
> wrote:
>
>>
>>How did you copy the dump file from Windows to Ubuntu?
>
> cvs2svn was executed on Ubuntu. The dump file was gzipped and then
> moved
On Wed, 13 Dec 2017 17:22:48 +0100, Stefan Sperling
wrote:
>
>How did you copy the dump file from Windows to Ubuntu?
cvs2svn was executed on Ubuntu. The dump file was gzipped and then
moved via FTP *to* Windows.
>Beware of Windows tools which change line endings!
>I have seen
On Wed, Dec 13, 2017 at 03:33:45PM +0100, Bo Berglund wrote:
> While investigating the methods to use when migrating our CVS
> repositories from CVS to SVN I converted one of the smaller CVS
> respositories to an svn dump file using cvs2svn 2.5.0 on an Ubuntu
> Server 16.04.3 machine.
On 13.12.2017 15:33, Bo Berglund wrote:
> While investigating the methods to use when migrating our CVS
> repositories from CVS to SVN I converted one of the smaller CVS
> respositories to an svn dump file using cvs2svn 2.5.0 on an Ubuntu
> Server 16.04.3 machine.
>
> Then I m
While investigating the methods to use when migrating our CVS
repositories from CVS to SVN I converted one of the smaller CVS
respositories to an svn dump file using cvs2svn 2.5.0 on an Ubuntu
Server 16.04.3 machine.
Then I moved the dump file over to the target Windows 2016 Server
where I had
On Fri, Oct 2, 2015 at 3:26 AM, Yves Martin wrote:
> Hello,
>
> The problem I face now when using "svnadmin dump" is "svndumpfilter:
> E23: Invalid copy source path' when selecting the three /trunk modules I
> am interested in.
> Such a problem "svnrdump" does not produce.
>
> Thank you in ad
Hello,
The problem I face now when using "svnadmin dump" is "svndumpfilter:
E23: Invalid copy source path' when selecting the three /trunk modules
I am interested in.
Such a problem "svnrdump" does not produce.
Thank you in advance for your help
--
Yves Martin
On Thu, 2015-10-01 at 09:29 -0400, Nico Kadel-Garcia wrote:
> If you're doing an rsync or scp to a remote system and doing the
> svndump there, you're running the risk of transferring content in the
> middle of an atomic operation and thus confusing the system.
>
> > svnrdump dump -r 51686:77787
On Oct 1, 2015, at 8:29, Nico Kadel-Garcia wrote:
>
> On Thu, Oct 1, 2015 at 4:19 AM, Yves Martin wrote:
>> Hello,
>>
>> I have a Subversion 1.6.17 server running on Debian Linux and access through
>> HTTPS.
>>
>> I used both Subversion 1.8.10 and Subversion 1.9.2 to produce a partial dump
>>
On Thu, Oct 1, 2015 at 4:19 AM, Yves Martin wrote:
> Hello,
>
> I have a Subversion 1.6.17 server running on Debian Linux and access through
> HTTPS.
>
> I used both Subversion 1.8.10 and Subversion 1.9.2 to produce a partial dump
> of the repository:
*Why*? If you have a subversion 1.6.17 serv
on fails as Text-content-md5 cannot be verified.
Load will handle svndiff format so that is not the cause of the failure.
> According to documentation svnrdump is compatible with Subversion server
> 1.4 for dump. What is wrong ?
Your dump file may be corrupt but you have not provided enoug
Hello,
I have a Subversion 1.6.17 server running on Debian Linux and access
through HTTPS.
I used both Subversion 1.8.10 and Subversion 1.9.2 to produce a partial
dump of the repository:
svnrdump dump -r 51686:77787
https://myhost/subversion/repository/PROJECT/trunk/amodule | gzip >
amodule.du
"Brown, Jonathan W" writes:
> Thanks for the quick attention, Phillip. I compiled a nightly
> snapshot of the source and tested it. Unfortunately, the filtered
> dump file format still appears incorrect.
Hmm, more ordering rules required, r1579274 should do it.
--
Philip
"Brown, Jonathan W" writes:
> Has anyone else come across this? I couldn't find any documented
> known issues/bugs on the matter. Any suggestions?
It's a bug. It's fixed it on trunk (r1578670) and proposed for 1.8.x.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
I am trying use svndumpfilter. I exported the repository and I am now trying
to run:
svndumpfilter exclude foo < a.dmp > b.dmp
The problem is that the generated dump file, 'b.dmp', is inconsistent with the
documented format (which is causing some other problems for me):
https:
> From: Thomas Harold
> Sent: Friday, 23 August 2013 11:53 AM
> On 8/22/2013 7:11 PM, Geoff Field wrote:
> Most restores for us took about 5-10 minutes, a few of our
> larger repos took a few hours.
I was doing this all in the background via remote login to our SVN server, so I
didn't monitor ti
Step 6 created the repos in our system with writable permissions, so we
had to make sure nobody could commit to the repo while we loaded back i
the dump file in step 9.
Most restores for us took about 5-10 minutes, a few of our larger repos
took a few hours.
On your OS, is there a way to read t
ot;svnadmin verify" on the original repository.
Probably something I should have done, but luckily I ended up with no obvious
failures in the dumps.
> 4. Do the "svnadmin dump", piping the output into gzip -5
> (moderate compression).
If you're removing the old repo, I
i
on = false[#[:space:]]*$/enable-dir-deltification =
true/g;s/^[#[:space:]]*enable-props-deltification =
false[#[:space:]]*$/enable-p
rops-deltification = true/g' --in-place=.bkp ${BASE}${DIR}/db/fsfs.conf
status=$?
if [ $status -ne 0 ]; then
echo "sed adjustment of db/fsfs.conf failed
From: Nico Kadel-Garcia
Sent: Thursday, 22 August 2013 8:10 AM
I would never do a transfer like this without a copy of the dumpfile available,
for reference. The pain of having to re-run the dump later, especially if there
are any bugs in the "svnadmin load" conf
, our largest repository (some 19,000 revisions
> with many files, including installation packages) is dumping. In the 5300
> range of revisions, the dump file has just passed 9GB.
>
> Shouldn't be a problem within the limits of the OS and filesystem.
> However, I'd sa
> From: Thorsten Schöning
> Sent: Wednesday, 21 August 2013 17:21 PM
> Guten Tag Geoff Field,
> am Mittwoch, 21. August 2013 um 08:29 schrieben Sie:
>
> > I've just realised that my concern was based on a power-of-2
> > limitation that means that a 32-bit signed integer would
> roll over at
> >
Guten Tag Geoff Field,
am Mittwoch, 21. August 2013 um 08:29 schrieben Sie:
> I've just realised that my concern was based on a power-of-2
> limitation that means that a 32-bit signed integer would roll over
> at the 2GB mark, with an unsigned roll-over at 4GB. It's possible
> the Windows Server
> From: Ben Reser
> Sent: Wednesday, 21 August 2013 17:07 PM
>
> On 8/20/13 11:29 PM, Geoff Field wrote:
> > Note that we have the old version 1.2.3 server software installed at
> > the C:\Program Files\Subversion location, and later versions
> > are stored under other locations, with the path se
On 8/20/13 11:29 PM, Geoff Field wrote:
> Note that we have the old version 1.2.3 server software installed at
the C:\Program Files\Subversion location, and later versions are stored
under other locations, with the path set to point to the new version.
I'm creating the new repositories with the old
ssfully. Right now, our largest repository
> > (some 19,000 revisions with many files, including
> > installation packages) is dumping. In the 5300 range of
> > revisions, the dump file has just passed 9GB.
Overall, it got to about 29GB. Dump and load worked fine, although
les, including
> installation packages) is dumping. In the 5300 range of revisions, the dump
> file has just passed 9GB.
Shouldn't be a problem within the limits of the OS and filesystem.
However, I'd say why are you bothering to produce dump files? Why not
simply pipe the output of your
ly. Right now,
our largest repository (some 19,000 revisions with many files, including
installation packages) is dumping. In the 5300 range of revisions, the dump
file has just passed 9GB.
Am I going to run into problems, or is it open-ended? This probably comes down
to the data type of the
Hello,
Any ideas what caused this crash?
Thanks,
Forest
--
Forest Handford, Supervisor Development, 781-774-5148
Medical Information Technology, Inc.
Mailstop: S4W186W, MEDITECH Circle, Westwood, MA 02090
svn-crash-log20121022091323.log
Description: Binary data
18:33:53 +0200:
> Hello,
>
> I try to convert SVN repository from bdb to fsfs format. But when I try to
> generate dump file, I get an error with description to send you the .log
> file. Could you please tell me what could be wrong? Thanks.
>
> Best regards,
> Andrej Kicina
Hello,
I try to convert SVN repository from bdb to fsfs format. But when I try to
generate dump file, I get an error with description to send you the .log
file. Could you please tell me what could be wrong? Thanks.
Best regards,
Andrej Kicina
svn-crash-log20111027183213.log
Description: Binary
On Aug 31, 2011, at 18:14 , Fernandes-Bastos, Joao / Kuehne + Nagel / Lux FY-P
wrote:
> Hi all,
>
> Actually I have a problem that I can’t figure out.
>
> I have included the dump file.
The crash-dump file doesn't tell us much. What were you doing
when the proble
Hi all,
Actually I have a problem that I can't figure out.
I have included the dump file.
Please help.
Thanks & Regards
JF
svn-crash-log20110831181047.log
Description: svn-crash-log20110831181047.log
Re: Checksum failed after using sed to modify paths in dump file in
spite of using ^
>On Aug 10, 2011, at 02:11, Peter Pommelich wrote:
>
>>> I used svndumpfilter to extract only the wanted folders from the original
>>> 'big' dump file.
>&
On Aug 10, 2011, at 02:11, Peter Pommelich wrote:
>> I used svndumpfilter to extract only the wanted folders from the original
>> 'big' dump file.
>>
>> I tried using the svndumptool but somehow I don't get it:
>>
>> svndumptool.py transform
Hi,
I just used perl for editing the dump file (perl -e "s/^Node-path:
trunk\/meta\//Node-path: /g;" -pi.bak ) and it just worked.
I hope that I do not need to nbother you again with that :-)
Kind reagrds and thanks a lot,
pete
-Ursprüngliche Nachricht-
Von: "
Hi,
I used svndumpfilter to extract only the wanted folders from the original 'big'
dump file.
I tried using the svndumptool but somehow I don't get it:
svndumptool.py transform-prop Node-path "^Node-path: trunk/meta/" "Node-path: "
DumpFinal.dump Dump
On Aug 9, 2011, at 04:16, Peter Pommelich wrote:
> I have to modify some paths (trunk/meta/trunk => trunk) in the dump file
> created with 'svnadmin dump'. I did the modification of 'Node-path' and
> 'Node-copyfrom-path' with sed.
Do not use sed to
Hi everbody,
I wrote to this mailing list a few days ago (I had some questions regarding how
to migrate a repository). I'm still working in this...
The current problem I have is this:
I have to modify some paths (trunk/meta/trunk => trunk) in the dump file
created with 'svnadmin
>From the svndumptoll documentation I see that the dump must be version 2, i.e.
>be created with the --deltas option. Does anybody know if that's what
>svnimporter does? I have looked on the Polarion website but I didn't find an
>answer. Also, is there a way, from looking at
...
>
> But I've adjusted my script now, any files the script identifies
> (by extension) as needing svn:eol-style=native are appropriately
> translated into the dump file.
>
OK
> Anyone here interested in looking-at/experimenting-with the
> powershell script let me know
ript now, any files the script identifies
(by extension) as needing svn:eol-style=native are appropriately
translated into the dump file.
I am quite pleased with the result, it certainly seems to solve
my file time-stamp problem well enough. Still to do some more
testing but it looks promising.
Anyone
Geoff Worboys wrote on Wed, 23 Jun 2010 at 04:12 -:
> Daniel Shahaf wrote:
> > i.e., 'svnadmin dump' produces CRLF for svn:eol-style=native
> > files? That surprises me; I'd expect such files to be
> > outputted with LF in dump files. (My testing agrees with my
> > expectation.) Can you doub
nt
astray there. I have vague memories of playing with the dump
files back when I created this repository so it may be a
problem that I caused ... or not.
It does appear that svnadmin accepts the dump file as the
literal truth - with minimal validation. For example I had
originally tried using
Geoff Worboys wrote on Tue, 22 Jun 2010 at 17:36 -:
> powershell .\Import-from-Source D:\SourceFolder D:\Temp\DumpFile.dat
>
> It takes the entire contents of D:\SourceFolder and creates
> a subversion dump file in D:\Temp\DumpFile.dat. It replicates
> the structure inside D:\
like an interesting project to try with it.
I have a working script now, put simply it is executed as:
powershell .\Import-from-Source D:\SourceFolder D:\Temp\DumpFile.dat
It takes the entire contents of D:\SourceFolder and creates
a subversion dump file in D:\Temp\DumpFile.dat. It replicates
the
On Tuesday 06 April 2010 11:49:54 Bretin Luc-Patrick (SILICOM) wrote:
> One of my collegues dump the svn repository and sent it to me.
> I try to load it in my svn server and it returns this error :
> 'vnadmin: Le flux de sauvegarde contient une entête mal formée (sans ':')
> à ' In english : dum
#x27;:') at '
I tried in two different svn server and I had the same error.
I find any solution at my problem, I hope you'll find one.
If you need more informations, just ask me.
Thanks in advance.
Best regards,
Luc-Patrick Bretin
The beginning of my dump file is :
SVN-fs-dum
49 matches
Mail list logo
