Hello everybody,
I have already posted this one one week ago, but no answer yet, so I try
again... :p
I am using the following:
* svn, version 1.2.3 (r15833) compiled Aug 26 2005, 03:42:45
* Linux fboulepc 2.6.15-1.1833_FC4smp #1 SMP Wed Mar 1 23:56:51 EST 2006
i686 i686 i386 GNU/Linux
In my repository, I work with proj/trunk (stable) and
proj/branches/proj_dev (development). The respective sandboxes are
l~/Projects/proj and ~/Projects/proj_dev.
Now when I want to merge the latest modifications to the trunk, I type:
[fboule@fboulepc proj]$ cd ~/Projects/proj
[fboule@fboulepc proj]$ svn merge -r committed:head ../proj_dev .
However, it doesn't work as expected (as I would expect I should maybe
say).
An example hereafter:
[fboule@fboulepc proj]$ svn update
At revision 247.
[fboule@fboulepc proj]$ svn info
Path: .
URL: file:///home/svn/WEB/proj/trunk
Repository UUID: 3dc7c77c-889d-2f49-9d6b-63af54285b16
Revision: 247
Node Kind: directory
Schedule: normal
Last Changed Author: fboule
Last Changed Rev: 243
Last Changed Date: 2006-05-23 11:42:06 +0000 (Tue, 23 May 2006)
And now:
[fboule@fboulepc proj]$ svn merge --dry-run -r COMMITTED:HEAD
../proj_dev/ .
[fboule@fboulepc proj]$
I would expect the following:
[fboule@fboulepc proj]$ svn merge --dry-run -r 243:HEAD ../proj_dev/ .
U fndisplay.php
U frmmain.php
U changelog.txt
U frmtemplate_part1.php
Am I doing something wrong?
Best Regards,
Fabien
----- Forwarded by Fabien Bouleau/BTZ on 02/06/2006 15:38 -----
users-digest-help
@subversion.tigri
s.org To
users@subversion.tigris.org
24/05/2006 22:15 cc
Subject
users Digest 24 May 2006 20:15:16
-0000 Issue 1755
users Digest 24 May 2006 20:15:16 -0000 Issue 1755
Topics (messages 49649 through 49678):
svn log timestamp bug?
49649 by: Johnathan Gifford
49652 by: Andy Levy
49653 by: Johnathan Gifford
49654 by: Ryan Schmidt
49655 by: Ryan Schmidt
49658 by: Johnathan Gifford
49659 by: Gale, David
Re: WARNING(virus check bypassed): Repos on Linux (RH9), want to view
offline on Windows
49650 by: Nico Kadel-Garcia
49657 by: Britain Crooker
Re: Question about svn lock
49651 by: Nico Kadel-Garcia
Re: More debug info options than "neon-debug-mask = 130"?
49656 by: Jeff Jensen
Import Option Using Subversion
49660 by: Shankaramurthy, Nagaraj
49665 by: Ryan Schmidt
problem with setting up the httpd.conf file
49661 by: CLAYTON LUIZ DE ANDRADE
49664 by: Edward Bosco
49666 by: Ryan Schmidt
49668 by: CLAYTON LUIZ DE ANDRADE
CPU usage during commits
49662 by: Sinang, Danny
49667 by: Ryan Schmidt
49669 by: Andy Levy
49670 by: Simon Butler
49671 by: Ryan Schmidt
49676 by: Simon Butler
49678 by: Garrett Rooney
FSFS / svn client time outs
49663 by: Sinang, Danny
...is not a working copy directory
49672 by: George Georgalis
49673 by: George Georgalis
49674 by: Trevor Whitlock
Re: Recover after HD crash (SVN with FSFS backend)
49675 by: Blair Zajac
Re: ranlib: command not found - Subversion1.3.1 Make install on Solaris9
49677 by: ilmars.katajs-paeglis.chase.com
Administrivia:
To subscribe to the digest, e-mail:
users-digest-subscribe@subversion.tigris.org
To unsubscribe from the digest, e-mail:
users-digest-unsubscribe@subversion.tigris.org
To post to the list, e-mail:
users@subversion.tigris.org
----------------------------------------------------------------------
----- Message from Johnathan Gifford <jgifford@wernervas.com> on Wed, 24
May 2006 07:26:37 -0500 -----
To: 'SVN Users email list' <users@subversion.tigris.org>
Subject: svn log timestamp bug?
When I run the below svn command:
svn log -v -r {2006-05-17T00:05}:{2006-05-24T00:05} --username XXXX
--password XXXX http://myserver.com/to/my/path
In the results I consistently get this revision:
r14662 | jdoe | 2006-05-16 17:18:43 -0500 (Tue, 16 May 2006) | 1 line
The timestamps used specify any revision between 5/17/2006 at 12:05 AM to
5/24/2006 at 12:05 AM should be outputted. But this result is dated
5/16/2006 at 5:18 PM?!?!?!? It is not in the timestamp range. Even if you
include the offset (-0500) that still doesn't put it in the range. Should
this be showing up? I've also tried other timestamp formats (
http://svnbook.red-bean.com/nightly/en/svn.tour.revs.html#svn.tour.revs.dates
) and also get the same revision showing up.
Subversion 1.3.0
Apache 2.2
Mac OS X 10.4.5
Johnathan
----- Message from "Andy Levy" <andy.levy@gmail.com> on Wed, 24 May 2006
08:39:40 -0400 -----
To: "Johnathan Gifford" <jgifford@wernervas.com>
cc: "SVN Users email list" <users@subversion.tigris.org>
Subject: Re: svn log timestamp bug?
On 5/24/06, Johnathan Gifford <jgifford@wernervas.com> wrote:
>
> When I run the below svn command:
>
> svn log -v -r {2006-05-17T00:05}:{2006-05-24T00:05}
> --username XXXX --password XXXX http://myserver.com/to/my/path
>
> In the results I consistently get this revision:
>
> r14662 | jdoe | 2006-05-16 17:18:43 -0500 (Tue, 16 May 2006) | 1 line
>
> The timestamps used specify any revision between 5/17/2006 at 12:05 AM
to
> 5/24/2006 at 12:05 AM should be outputted. But this result is dated
> 5/16/2006 at 5:18 PM?!?!?!? It is not in the timestamp range. Even if
you
> include the offset (-0500) that still doesn't put it in the range.
Should
> this be showing up? I've also tried other timestamp formats (
>
http://svnbook.red-bean.com/nightly/en/svn.tour.revs.html#svn.tour.revs.dates
> ) and also get the same revision showing up.
When you do revisions by date/time, the current revision at the start
time is what was reported. So, if at 2006-05-17T00:05, the current
latest revision is what was checked in at 2006-05-16 17:18:43 -0500,
that's what will be reported as the first revision in the log.
It took me an hour or two while working on my log reporting script to
reconcile this in my head too.
What's the timestamp on revision 14663? It should be later than
2006-05-17T00:05 If it's not, then there might be a bug.
----- Message from Johnathan Gifford <jgifford@wernervas.com> on Wed, 24
May 2006 07:54:27 -0500 -----
To: Andy Levy <andy.levy@gmail.com>
cc: SVN Users email list <users@subversion.tigris.org>
Subject: Re: svn log timestamp bug?
On 5/24/06 7:39 AM, "Andy Levy" <andy.levy@gmail.com> wrote:
> On 5/24/06, Johnathan Gifford <jgifford@wernervas.com> wrote:
>>
>> When I run the below svn command:
>>
>> svn log -v -r {2006-05-17T00:05}:{2006-05-24T00:05}
>> --username XXXX --password XXXX http://myserver.com/to/my/path
>>
>> In the results I consistently get this revision:
>>
>> r14662 | jdoe | 2006-05-16 17:18:43 -0500 (Tue, 16 May 2006) | 1 line
>>
>> The timestamps used specify any revision between 5/17/2006 at 12:05 AM
to
>> 5/24/2006 at 12:05 AM should be outputted. But this result is dated
>> 5/16/2006 at 5:18 PM?!?!?!? It is not in the timestamp range. Even if
you
>> include the offset (-0500) that still doesn't put it in the range.
Should
>> this be showing up? I've also tried other timestamp formats (
>>
http://svnbook.red-bean.com/nightly/en/svn.tour.revs.html#svn.tour.revs.dates
>> ) and also get the same revision showing up.
>
> When you do revisions by date/time, the current revision at the start
> time is what was reported. So, if at 2006-05-17T00:05, the current
> latest revision is what was checked in at 2006-05-16 17:18:43 -0500,
> that's what will be reported as the first revision in the log.
>
> It took me an hour or two while working on my log reporting script to
> reconcile this in my head too.
>
> What's the timestamp on revision 14663? It should be later than
> 2006-05-17T00:05 If it's not, then there might be a bug.
The next revision in that path:
r14696 | jdoe | 2006-05-17 15:30:47 -0500 (Wed, 17 May 2006) | 1 line
I've been running a report script for four weeks with the above command and
this is the first time this anomaly has shown up. I would agree with your
statement about the latest revision if I was only looking one day, but I'm
searching by a range. I would expect only revisions between that range to
be returned.
----- Message from Ryan Schmidt <subversion-2006q2@ryandesign.com> on Wed,
24 May 2006 14:59:46 +0200 -----
To: Johnathan Gifford <jgifford@wernervas.com>
cc: 'SVN Users email list' <users@subversion.tigris.org>
Subject: Re: svn log timestamp bug?
On May 24, 2006, at 14:26, Johnathan Gifford wrote:
> When I run the below svn command:
>
> svn log -v -r {2006-05-17T00:05}:{2006-05-24T00:05} --username XXXX
> --password XXXX http://myserver.com/to/my/path
>
> In the results I consistently get this revision:
>
> r14662 | jdoe | 2006-05-16 17:18:43 -0500 (Tue, 16 May 2006) | 1 line
>
> The timestamps used specify any revision between 5/17/2006 at 12:05
> AM to 5/24/2006 at 12:05 AM should be outputted. But this result
> is dated 5/16/2006 at 5:18 PM?!?!?!? It is not in the timestamp
> range. Even if you include the offset (-0500) that still doesn't
> put it in the range. Should this be showing up? I've also tried
> other timestamp formats ( http://svnbook.red-bean.com/nightly/en/
> svn.tour.revs.html#svn.tour.revs.dates ) and also get the same
> revision showing up.
As explained at the URL in the book you gave, Subversion will find
the most recent revision as of the given date/time -- meaning, it'll
give you the revision on or before that date/time:
> When you specify a date as a revision, Subversion finds the most
> recent revision of the repository as of that date:
>
> $ svn log --revision {2002-11-28}
> ----------------------------------------------------------------------
> --
> r12 | ira | 2002-11-27 12:31:51 -0600 (Wed, 27 Nov 2002) | 6 lines
> …
If you ask for {2006-05-17T00:05} but the last change you made before
2006-05-17T00:05 was on 2006-05-16T17:18:43, then you'll get the
revision from 2006-05-16T17:18:43.
----- Message from Ryan Schmidt <subversion-2006q2@ryandesign.com> on Wed,
24 May 2006 15:13:22 +0200 -----
To: Johnathan Gifford <jgifford@wernervas.com>
cc: Andy Levy <andy.levy@gmail.com>, SVN Users email list
<users@subversion.tigris.org>
Subjec Re: svn log timestamp bug?
t:
On May 24, 2006, at 14:54, Johnathan Gifford wrote:
>> When you do revisions by date/time, the current revision at the start
>> time is what was reported. So, if at 2006-05-17T00:05, the current
>> latest revision is what was checked in at 2006-05-16 17:18:43 -0500,
>> that's what will be reported as the first revision in the log.
>>
>> It took me an hour or two while working on my log reporting script to
>> reconcile this in my head too.
>>
>> What's the timestamp on revision 14663? It should be later than
>> 2006-05-17T00:05 If it's not, then there might be a bug.
>
> The next revision in that path:
>
> r14696 | jdoe | 2006-05-17 15:30:47 -0500 (Wed, 17 May 2006) | 1 line
>
> I've been running a report script for four weeks with the above
> command and
> this is the first time this anomaly has shown up. I would agree
> with your
> statement about the latest revision if I was only looking one day,
> but I'm
> searching by a range. I would expect only revisions between that
> range to
> be returned.
Well, that's not what Subversion does, and that's not what's
described in the book.
----- Message from Johnathan Gifford <jgifford@wernervas.com> on Wed, 24
May 2006 08:35:08 -0500 -----
To: Ryan Schmidt <subversion-2006q2@ryandesign.com>
cc: Andy Levy <andy.levy@gmail.com>, SVN Users email list
<users@subversion.tigris.org>
Subjec Re: svn log timestamp bug?
t:
On 5/24/06 8:13 AM, "Ryan Schmidt" <subversion-2006q2@ryandesign.com>
wrote:
> On May 24, 2006, at 14:54, Johnathan Gifford wrote:
>
>>> When you do revisions by date/time, the current revision at the start
>>> time is what was reported. So, if at 2006-05-17T00:05, the current
>>> latest revision is what was checked in at 2006-05-16 17:18:43 -0500,
>>> that's what will be reported as the first revision in the log.
>>>
>>> It took me an hour or two while working on my log reporting script to
>>> reconcile this in my head too.
>>>
>>> What's the timestamp on revision 14663? It should be later than
>>> 2006-05-17T00:05 If it's not, then there might be a bug.
>>
>> The next revision in that path:
>>
>> r14696 | jdoe | 2006-05-17 15:30:47 -0500 (Wed, 17 May 2006) | 1 line
>>
>> I've been running a report script for four weeks with the above
>> command and
>> this is the first time this anomaly has shown up. I would agree
>> with your
>> statement about the latest revision if I was only looking one day,
>> but I'm
>> searching by a range. I would expect only revisions between that
>> range to
>> be returned.
>
> Well, that's not what Subversion does, and that's not what's
> described in the book.
>
>
Beg to differ. I also run the same command on two other repository paths
using the same date range. Because there are hardly ever any changes on
these paths I always get an empty response ( see 'Why Does svn log Give Me
an Empty Response?' at
http://svnbook.red-bean.com/nightly/en/svn.tour.history.html#svn.tour.histor
y.log ).
As far as what the book describes (
http://svnbook.red-bean.com/nightly/en/svn.tour.revs.html#svn.tour.revs.date
s ), it only refers to a single date for the revision. There is no
information in regards to searching by a revision range using dates. I
would expect a date range to only return revisions in the date range.
r14696 is in revision range and should be in the list, however, r14662 is
not in the revision range and should NOT be in the return list.
----- Message from "Gale, David" <David.Gale@Hypertherm.com> on Wed, 24 May
2006 09:47:02 -0400 -----
To: "Ryan Schmidt" <subversion-2006q2@ryandesign.com>, "Johnathan
Gifford" <jgifford@wernervas.com>
cc: "Andy Levy" <andy.levy@gmail.com>, "SVN Users email list"
<users@subversion.tigris.org>
Subje RE: Re: svn log timestamp bug?
ct:
Ryan Schmidt wrote:
> On May 24, 2006, at 14:54, Johnathan Gifford wrote:
>
>>> When you do revisions by date/time, the current revision at the
>>> start time is what was reported. So, if at 2006-05-17T00:05, the
>>> current latest revision is what was checked in at 2006-05-16
>>> 17:18:43 -0500, that's what will be reported as the first revision
>>> in the log.
>>>
>>> It took me an hour or two while working on my log reporting script
>>> to reconcile this in my head too.
>>>
>>> What's the timestamp on revision 14663? It should be later than
>>> 2006-05-17T00:05 If it's not, then there might be a bug.
>>
>> The next revision in that path:
>>
>> r14696 | jdoe | 2006-05-17 15:30:47 -0500 (Wed, 17 May 2006) | 1 line
>>
>> I've been running a report script for four weeks with the above
>> command and this is the first time this anomaly has shown up. I
>> would agree with your statement about the latest revision if I was
>> only looking one day, but I'm searching by a range. I would expect
>> only revisions between that range to be returned.
>
> Well, that's not what Subversion does, and that's not what's
> described in the book.
Actually, it *is* what's described in the book:
(http://svnbook.red-bean.com/nightly/en/svn.tour.revs.html#svn.tour.revs
.dates)
"You can also use a range of dates. Subversion will find all revisions
between both dates, inclusive:"
I played around with this a bit, and I couldn't convince myself that
subversion was handling things correctly (or, at least, consistently):
$ svn log -q -r{2005-11-22T00:05}:{2005-11-30T00:05} <file>.pl
------------------------------------------------------------------------
r17 | dgale | 2005-11-11 09:48:08 -0500 (Fri, 11 Nov 2005)
------------------------------------------------------------------------
r18 | dgale | 2005-11-23 10:04:04 -0500 (Wed, 23 Nov 2005)
------------------------------------------------------------------------
r25 | dgale | 2005-11-29 08:12:01 -0500 (Tue, 29 Nov 2005)
------------------------------------------------------------------------
r27 | dgale | 2005-11-29 17:18:53 -0500 (Tue, 29 Nov 2005)
------------------------------------------------------------------------
# The r17, which is clearly earlier than the requested range, mirrors
what Johnathan is seeing.
$ svn log -q -r{2005-11-23T00:05}:{2005-11-30T00:05} <file>.pl
------------------------------------------------------------------------
r25 | dgale | 2005-11-29 08:12:01 -0500 (Tue, 29 Nov 2005)
------------------------------------------------------------------------
r27 | dgale | 2005-11-29 17:18:53 -0500 (Tue, 29 Nov 2005)
------------------------------------------------------------------------
# r18 doesn't show up, despite that being the last version of the file
before the requested range.
Either I'm misunderstanding something, or one of these two commands
isn't working as expected. (I'd argue that the first command isn't
working, since "svn log -r20:30 <file>.pl" only reports revisions 25 and
28--revision 18 is out of range.)
-David
----- Message from "Nico Kadel-Garcia" <nkadel@comcast.net> on Wed, 24 May
2006 08:34:02 -0400 -----
To: "Britain Crooker" <britainc@fifthorder.com>,
<users@subversion.tigris.org>
Subjec Re: WARNING(virus check bypassed): Repos on Linux (RH9), want to
t: view offline on Windows
Britain Crooker wrote:
> Using SVN 1.3.1, I have a server (using the svnserver, not WebDAV)
> running on our main server, which works great. Clients are all
> Windows users using TortoiseSVN.
>
> I do daily backups of the repositories (using the hotcopy command)
> which I am able to restore on the linux server and access fine, so
> they seem valid. If I take the same backup (which was compressed to a
> tar.gz file after the hotcopy) and extract it on my laptop, I am
> unable to browse it with Tortoise or with the SVN command line tools.
> They complain about "Unable to open an ra_lcoal session to URL" and
> that FSFS is an unknown file type.
>
> I had thought that FSFS was supposed to be platform independent, so I
> figured what I was trying to do should be possible.
>
> I would really like to be able to copy the repositories onto my
> laptop so that when I am traveling, or otherwise disconnected from
> the internet, I can browse the source history.
Hmm. Does it work if you do a simple "svnadmin create" on the Windows
server, just to make sure that other things are working?
----- Message from "Britain Crooker" <britainc@fifthorder.com> on Wed, 24
May 2006 09:27:33 -0400 -----
To: "'Nico Kadel-Garcia'" <nkadel@comcast.net>,
<users@subversion.tigris.org>
Subjec RE: WARNING(virus check bypassed): Repos on Linux (RH9), want to
t: view offline on Windows
> -----Original Message-----
> From: Nico Kadel-Garcia [mailto:nkadel@comcast.net]
> Sent: Wednesday, May 24, 2006 8:34 AM
> To: Britain Crooker; users@subversion.tigris.org
> Subject: Re: WARNING(virus check bypassed): Repos on Linux
> (RH9), want to view offline on Windows
>
> Britain Crooker wrote:
> > Using SVN 1.3.1, I have a server (using the svnserver, not WebDAV)
> > running on our main server, which works great. Clients are all
> > Windows users using TortoiseSVN.
> >
> > I do daily backups of the repositories (using the hotcopy command)
> > which I am able to restore on the linux server and access fine, so
> > they seem valid. If I take the same backup (which was
> compressed to a
> > tar.gz file after the hotcopy) and extract it on my laptop, I am
> > unable to browse it with Tortoise or with the SVN command
> line tools.
> > They complain about "Unable to open an ra_lcoal session to URL" and
> > that FSFS is an unknown file type.
> >
> > I had thought that FSFS was supposed to be platform
> independent, so I
> > figured what I was trying to do should be possible.
> >
> > I would really like to be able to copy the repositories
> onto my laptop
> > so that when I am traveling, or otherwise disconnected from the
> > internet, I can browse the source history.
>
> Hmm. Does it work if you do a simple "svnadmin create" on the
> Windows server, just to make sure that other things are working?
>
>
I have tried to create a new FSFS repository, both with the svnadmin
command
and via the TortoiseSVN interface, both work fine (in fact I created the
current FSFS repositories on my Windows laptop because they were initially
in the BDB format and had to be switched over to FSFS because our RH9
didn't
support the right version of BDB. So I did a dump and load to switch
formats, and then copied the resulting files up to the Linux box).
----- Message from "Nico Kadel-Garcia" <nkadel@comcast.net> on Wed, 24 May
2006 08:35:23 -0400 -----
To: "Senthil Kumarasamy" <Senthil.Kumarasamy@relayhealth.com>,
<users@subversion.tigris.org>
Subjec Re: Question about svn lock
t:
If you need to lock entire directories, you might want to seriously look
into doing user access control for it. svnperms.py and svnperms.conf are
good examples of how to do that.
----- Original Message -----
From: Senthil Kumarasamy
To: users@subversion.tigris.org
Sent: Tuesday, May 23, 2006 12:54 PM
Subject: Question about svn lock
Is it possible to lock entire directory using sn lock?
Thanks
Senthil
----- Message from "Jeff Jensen" <jeffjensen@upstairstechnology.com> on
Wed, 24 May 2006 08:20:25 -0500 -----
To: <users@subversion.tigris.org>
Subject: RE: More debug info options than "neon-debug-mask = 130"?
For the archives, this MS KB article and patch was needed to solve our ISA
problem:
http://support.microsoft.com/kb/304340/en-us
So there is a bug in the 2000 version of ISA that it fixes. There wasn't
anything configurable that was blocking the requests.
Thank you again for the big help in tracking this down.
> -----Original Message-----
> From: Jeff Jensen [mailto:jeffjensen@upstairstechnology.com]
> Sent: Monday, May 22, 2006 9:56 PM
> To: 'Garrett Rooney'
> Cc: users@subversion.tigris.org
> Subject: RE: More debug info options than "neon-debug-mask = 130"?
>
>
> > -----Original Message-----
> > From: rooneg@gmail.com [mailto:rooneg@gmail.com] On Behalf
> Of Garrett
> > Rooney
> > Sent: Monday, May 22, 2006 9:33 PM
> > To: Jeff Jensen
> > Cc: users@subversion.tigris.org
> > Subject: Re: More debug info options than "neon-debug-mask = 130"?
> >
> > On 5/22/06, Jeff Jensen <jeffjensen@upstairstechnology.com> wrote:
> >
> > > Before we blame ISA, does this test also prove that
> nothing on the
> > > Linux server hosting svn is blocking too, or did this
> > tunnel blow by
> > > any of that too?
> >
> > Unless there's a really weird firewall running on your server, I'd
> > suspect that the ISA proxy is your problem.
>
> Thanks a ton for your help! Very much appreciated and needed.
> (Now to determine what to change on ISA. I couldn't see
> today how it was blocking anything!)
----- Message from "Shankaramurthy, Nagaraj"
<Nagaraj.Shankaramurthy@acs-inc.com> on Wed, 24 May 2006 08:11:30 -0500
-----
To: users@subversion.tigris.org
Subject: Import Option Using Subversion
Hi All,
I am trying to import a folder on C:\ with name _Development to SVN
Repository. The Size of folder is nearly 5GB with 39,931 Files and 2244
folders.
Steps I followed to import the folder:
Right Click on the Folder à Select TortoiseSVN à Goto Import à Select
Subversion Repository and Click on OK.
After Importing 30 to 50MB of data Subversion crashes and fails to import
the folder contents. Even, apache server fails and needs to be restarted.
Is there any other method to importing a large folder structure to
Subversion?
Please let me know.
Thanks and Regards,
Nagaraj S
----- Message from Ryan Schmidt <subversion-2006q2@ryandesign.com> on Wed,
24 May 2006 16:46:06 +0200 -----
To: "Shankaramurthy, Nagaraj" <Nagaraj.Shankaramurthy@acs-inc.com>
cc: users@subversion.tigris.org
Subject: Re: Import Option Using Subversion
On May 24, 2006, at 15:11, Shankaramurthy, Nagaraj wrote:
> Is there any other method to importing a large folder structure to
> Subversion?
Yes, there is the so-called "in-place import":
http://subversion.tigris.org/faq.html#in-place-import
----- Message from "CLAYTON LUIZ DE ANDRADE" <claytonl@agraria.com.br> on
Wed, 24 May 2006 10:11:28 -0300 -----
To: <users@subversion.tigris.org>
Subject: problem with setting up the httpd.conf file
Hi all,
I am using Apache 2.2.2 server and install Subversion 1.3.1 under Windowx
XP SP2.
When I put all recommended modifications (httpd.conf)
like:
LoadModule dav_module modules/mod_dav.so
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule dav_fs_module modules/mod_dav_fs.so
and try re-start the Apache Server the following error appears:
httpd.exe: Syntax error on line 85 of C:/Arquivos de programas/Apache
Software F
oundation/Apache2.2/conf/httpd.conf: API module structure `dav_svn_module'
in fi
le C:/Arquivos de programas/Apache Software
Foundation/Apache2.2/modules/mod_dav
_svn.so is garbled - perhaps this is not an Apache module DSO?
Note the errors or messages above, and press the <ESC> key to exit.
Please, help me.
Clayton Luiz de Andrade
Analista de Sistemas - Dept. de Informática Cooperativa Agrária Mista Entre Rios Ltda
Fone: (42) 3625-8107
claytonl@agraria.com.br
Visite: www.agraria.com.br
----- Message from "Edward Bosco" <ebosco@prologic-inc.com> on Wed, 24 May
2006 10:30:01 -0400 -----
To: "CLAYTON LUIZ DE ANDRADE" <claytonl@agraria.com.br>,
<users@subversion.tigris.org>
Subjec RE: problem with setting up the httpd.conf file
t:
Clayton -
I don't believe that Apache 2.2.2 has support yet for the mod_dav_svn
module.
From http://subversion.tigris.org/faq.html
==
I heard that Subversion is an Apache extension? What does it use for
servers?
No. Subversion is a set of libraries. It comes with a command-line
client that uses them. There are two different Subversion server
processes: either svnserve, which is small standalone program similar to
cvs pserver, or Apache httpd-2.0 using a special mod_dav_svn module.
svnserve speaks a custom protocol, while mod_dav_svn uses WebDAV as its
network protocol. See chapter 6 in the Subversion book to learn more.
==
From
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig
==
Prerequisites
To network your repository over HTTP, you basically need four
components, available in two packages. You'll need Apache httpd 2.0, the
mod_dav DAV module that comes with it, Subversion, and the mod_dav_svn
filesystem provider module distributed with Subversion. Once you have
all of those components, the process of networking your repository is as
simple as:
*
getting httpd 2.0 up and running with the mod_dav module,
*
installing the mod_dav_svn plugin to mod_dav, which uses
Subversion's libraries to access the repository, and
*
configuring your httpd.conf file to export (or expose) the
repository.
You can accomplish the first two items either by compiling httpd and
Subversion from source code, or by installing pre-built binary packages
of them on your system. For the most up-to-date information on how to
compile Subversion for use with the Apache HTTP Server, as well as how
to compile and configure Apache itself for this purpose, see the INSTALL
file in the top level of the Subversion source code tree.
==
Try a backlevel apache 2.0.58?
-----Original Message-----
From: CLAYTON LUIZ DE ANDRADE [mailto:claytonl@agraria.com.br]
Sent: Wednesday, May 24, 2006 9:11 AM
To: users@subversion.tigris.org
Subject: problem with setting up the httpd.conf file
Hi all,
I am using Apache 2.2.2 server and install Subversion 1.3.1 under
Windowx XP SP2.
When I put all recommended modifications (httpd.conf)
like:
LoadModule dav_module modules/mod_dav.so
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule dav_fs_module modules/mod_dav_fs.so
and try re-start the Apache Server the following error appears:
httpd.exe: Syntax error on line 85 of C:/Arquivos de programas/Apache
Software F
oundation/Apache2.2/conf/httpd.conf: API module structure
`dav_svn_module' in fi
le C:/Arquivos de programas/Apache Software
Foundation/Apache2.2/modules/mod_dav
_svn.so is garbled - perhaps this is not an Apache module DSO?
Note the errors or messages above, and press the <ESC> key to exit.
Please, help me.
Clayton Luiz de Andrade
Analista de Sistemas - Dept. de Informática
Cooperativa Agrária Mista Entre Rios Ltda
Fone: (42) 3625-8107
claytonl@agraria.com.br
Visite: www.agraria.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
----- Message from Ryan Schmidt <subversion-2006q2@ryandesign.com> on Wed,
24 May 2006 16:48:35 +0200 -----
To: CLAYTON LUIZ DE ANDRADE <claytonl@agraria.com.br>
cc: <users@subversion.tigris.org>
Subject: Re: problem with setting up the httpd.conf file
On May 24, 2006, at 15:11, CLAYTON LUIZ DE ANDRADE wrote:
> I am using Apache 2.2.2 server and install Subversion 1.3.1 under
> Windowx XP SP2.
>
> When I put all recommended modifications (httpd.conf)
> like:
>
> LoadModule dav_module modules/mod_dav.so
> LoadModule dav_svn_module modules/mod_dav_svn.so
> LoadModule dav_fs_module modules/mod_dav_fs.so
>
> and try re-start the Apache Server the following error appears:
>
> httpd.exe: Syntax error on line 85 of C:/Arquivos de programas/
> Apache Software F
> oundation/Apache2.2/conf/httpd.conf: API module structure
> `dav_svn_module' in fi
> le C:/Arquivos de programas/Apache Software Foundation/Apache2.2/
> modules/mod_dav
> _svn.so is garbled - perhaps this is not an Apache module DSO?
> Note the errors or messages above, and press the <ESC> key to exit.
Subversion 1.3.1 works great with Apache 2.2.2. I'm using it right
now on Mac OS X. But the Subversion Apache module needs to be
compiled with the Apache 2.2 libraries for it to work there. Did you
compile Subversion, or did you use one of the pre-packaged binaries
linked to from the Subversion pages? If the latter, please note that
it says in big letters at the top of that page that the binaries
provided there are not compatible with Apache 2.2. If you want Apache
2.2 compatibility, build the module yourself.
----- Message from "CLAYTON LUIZ DE ANDRADE" <claytonl@agraria.com.br> on
Wed, 24 May 2006 11:35:28 -0300 -----
To: <ebosco@prologic-inc.com>,<users@subversion.tigris.org>
Subject: RE: problem with setting up the httpd.conf file
Thats it, I installed the Apache 2.0.58 and everything runs well, great!
Thanks a lot.
Clayton Luiz de Andrade
Analista de Sistemas - Dept. de Informática
Cooperativa Agrária Mista Entre Rios Ltda
Fone: (42) 3625-8107
claytonl@agraria.com.br
Visite: www.agraria.com.br
>>> "Edward Bosco" <ebosco@prologic-inc.com> 05/24/06 11:30 am >>>
Clayton -
I don't believe that Apache 2.2.2 has support yet for the mod_dav_svn
module.
From http://subversion.tigris.org/faq.html
==
I heard that Subversion is an Apache extension? What does it use for
servers?
No. Subversion is a set of libraries. It comes with a command-line
client that uses them. There are two different Subversion server
processes: either svnserve, which is small standalone program similar to
cvs pserver, or Apache httpd-2.0 using a special mod_dav_svn module.
svnserve speaks a custom protocol, while mod_dav_svn uses WebDAV as its
network protocol. See chapter 6 in the Subversion book to learn more.
==
From
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig
==
Prerequisites
To network your repository over HTTP, you basically need four
components, available in two packages. You'll need Apache httpd 2.0, the
mod_dav DAV module that comes with it, Subversion, and the mod_dav_svn
filesystem provider module distributed with Subversion. Once you have
all of those components, the process of networking your repository is as
simple as:
*
getting httpd 2.0 up and running with the mod_dav module,
*
installing the mod_dav_svn plugin to mod_dav, which uses
Subversion's libraries to access the repository, and
*
configuring your httpd.conf file to export (or expose) the
repository.
You can accomplish the first two items either by compiling httpd and
Subversion from source code, or by installing pre-built binary packages
of them on your system. For the most up-to-date information on how to
compile Subversion for use with the Apache HTTP Server, as well as how
to compile and configure Apache itself for this purpose, see the INSTALL
file in the top level of the Subversion source code tree.
==
Try a backlevel apache 2.0.58?
-----Original Message-----
From: CLAYTON LUIZ DE ANDRADE [mailto:claytonl@agraria.com.br]
Sent: Wednesday, May 24, 2006 9:11 AM
To: users@subversion.tigris.org
Subject: problem with setting up the httpd.conf file
Hi all,
I am using Apache 2.2.2 server and install Subversion 1.3.1 under
Windowx XP SP2.
When I put all recommended modifications (httpd.conf)
like:
LoadModule dav_module modules/mod_dav.so
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule dav_fs_module modules/mod_dav_fs.so
and try re-start the Apache Server the following error appears:
httpd.exe: Syntax error on line 85 of C:/Arquivos de programas/Apache
Software F
oundation/Apache2.2/conf/httpd.conf: API module structure
`dav_svn_module' in fi
le C:/Arquivos de programas/Apache Software
Foundation/Apache2.2/modules/mod_dav
_svn.so is garbled - perhaps this is not an Apache module DSO?
Note the errors or messages above, and press the <ESC> key to exit.
Please, help me.
Clayton Luiz de Andrade
Analista de Sistemas - Dept. de Informática
Cooperativa Agrária Mista Entre Rios Ltda
Fone: (42) 3625-8107
claytonl@agraria.com.br
Visite: www.agraria.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
----- Message from "Sinang, Danny" <D.Sinang@spi-bpo.com> on Wed, 24 May
2006 22:02:35 +0800 -----
To: <users@subversion.tigris.org>
Subject: CPU usage during commits
Hello,
In http://svnbook.red-bean.com/nightly/en/svn-book.html , it says :
Specifically, each time a new version of a file is committed to the
repository, Subversion encodes the previous version (actually, several
previous versions) as a delta against the new version.
On average, we'll be checking in 10 MB PDF or TIFF files . Will this
consume a lot of CPU or Disk I/O ? If so, how much ?
- Danny
----- Message from Ryan Schmidt <subversion-2006q2@ryandesign.com> on Wed,
24 May 2006 16:44:40 +0200 -----
To: "Sinang, Danny" <D.Sinang@spi-bpo.com>
cc: <users@subversion.tigris.org>
Subject: Re: CPU usage during commits
On May 24, 2006, at 16:02, Sinang, Danny wrote:
> In http://svnbook.red-bean.com/nightly/en/svn-book.html , it says :
>
> Specifically, each time a new version of a file is committed to the
> repository, Subversion encodes the previous version (actually,
> several previous versions) as a delta against the new version.
>
> On average, we'll be checking in 10 MB PDF or TIFF files . Will
> this consume a lot of CPU or Disk I/O ? If so, how much ?
Only BDB repositories do this. FSFS repositories do not do this.
----- Message from "Andy Levy" <andy.levy@gmail.com> on Wed, 24 May 2006
10:18:30 -0400 -----
To: "Sinang, Danny" <D.Sinang@spi-bpo.com>
cc: users@subversion.tigris.org
Subject: Re: CPU usage during commits
On 5/24/06, Sinang, Danny <D.Sinang@spi-bpo.com> wrote:
> In http://svnbook.red-bean.com/nightly/en/svn-book.html ,
> it says :
>
> Specifically, each time a new version of a file is committed to the
> repository, Subversion encodes the previous version (actually, several
> previous versions) as a delta against the new version.
>
> On average, we'll be checking in 10 MB PDF or TIFF files . Will this
consume
> a lot of CPU or Disk I/O ? If so, how much ?
Can't be answered without knowing the data and your hardware specs.
And even then, the answer is often variable.
But you could pretty easily set up a few test cases and check it out
for yourself.
----- Message from Simon Butler <simon@icmethods.com> on Wed, 24 May 2006
09:15:00 -0700 -----
To: Ryan Schmidt <subversion-2006q2@ryandesign.com>
cc: "Sinang, Danny" <D.Sinang@spi-bpo.com>,
<users@subversion.tigris.org>
Subject: Re: CPU usage during commits
On May 24, 2006, at 7:44 AM, Ryan Schmidt wrote:
>
> On May 24, 2006, at 16:02, Sinang, Danny wrote:
>
>> In http://svnbook.red-bean.com/nightly/en/svn-book.html , it says :
>>
>> Specifically, each time a new version of a file is committed to
>> the repository, Subversion encodes the previous version (actually,
>> several previous versions) as a delta against the new version.
>>
>> On average, we'll be checking in 10 MB PDF or TIFF files . Will
>> this consume a lot of CPU or Disk I/O ? If so, how much ?
>
> Only BDB repositories do this. FSFS repositories do not do this.
>
>
now i'm confused. for FSFS repositories what is the sequence of
operations for large binary files? i thought it was:
1) compare new version to previous version held in the working area,
generate delta
2) transfer binary delta to repos and store
what is the sequence for a new user checkout ? is the latest version
recreated from the layers of deltas in the repos?
is a pristine latest version kept in the repos?
i guess i'm confused as to where all these deltas occur and how they
are used.
note that binary deltas are time consuming and too many are going to
slow the whole mechanism down
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
----- Message from Ryan Schmidt <subversion-2006q2@ryandesign.com> on Wed,
24 May 2006 18:34:54 +0200 -----
To: Simon Butler <simon@icmethods.com>
cc: "Sinang, Danny" <D.Sinang@spi-bpo.com>,
<users@subversion.tigris.org>
Subject: Re: CPU usage during commits
On May 24, 2006, at 18:15, Simon Butler wrote:
> On May 24, 2006, at 7:44 AM, Ryan Schmidt wrote:
>
>> On May 24, 2006, at 16:02, Sinang, Danny wrote:
>>
>>> In http://svnbook.red-bean.com/nightly/en/svn-book.html , it says :
>>>
>>> Specifically, each time a new version of a file is committed to
>>> the repository, Subversion encodes the previous version
>>> (actually, several previous versions) as a delta against the new
>>> version.
>>>
>>> On average, we'll be checking in 10 MB PDF or TIFF files . Will
>>> this consume a lot of CPU or Disk I/O ? If so, how much ?
>>
>> Only BDB repositories do this. FSFS repositories do not do this.
>
> now i'm confused. for FSFS repositories what is the sequence of
> operations for large binary files? i thought it was:
The behavior is identical for binary and text files. Subversion sees
them no differently.
> 1) compare new version to previous version held in the working
> area, generate delta
> 2) transfer binary delta to repos and store
When you commit changes, yes, a delta against the pristine copy in
the working copy is computed and sent to the server, regardless of
repository type. (The working copy on the client does not know or
care how the repository is stored on the server). How the data is
subsequently stored in the repository differs based on repository
type. BDB stores the complete current version and rewrites the
previous revisions to be deltas against the current revision. FSFS on
the other hand stores a delta against some previous revision based on
some algorithm.
> what is the sequence for a new user checkout ? is the latest
> version recreated from the layers of deltas in the repos?
For FSFS, yes. For BDB, the latest revision contains the complete file.
> is a pristine latest version kept in the repos?
For BDB, yes. For FSFS, no; it's computed from the deltas.
> i guess i'm confused as to where all these deltas occur and how
> they are used.
>
> note that binary deltas are time consuming and too many are going
> to slow the whole mechanism down
I understand that Subversion has a good binary delta algorithm and
that it is used for all files, text or binary, and that improvements
in the algorithm are certainly welcomed.
----- Message from Simon Butler <simon@icmethods.com> on Wed, 24 May 2006
11:33:41 -0700 -----
To: Ryan Schmidt <subversion-2006q2@ryandesign.com>
cc: "Sinang, Danny" <D.Sinang@spi-bpo.com>,
<users@subversion.tigris.org>
Subject: Re: CPU usage during commits
On May 24, 2006, at 9:34 AM, Ryan Schmidt wrote:
> On May 24, 2006, at 18:15, Simon Butler wrote:
>
>> On May 24, 2006, at 7:44 AM, Ryan Schmidt wrote:
>>
>>> On May 24, 2006, at 16:02, Sinang, Danny wrote:
>>>
>>>> In http://svnbook.red-bean.com/nightly/en/svn-book.html , it says :
>>>>
>>>> Specifically, each time a new version of a file is committed to
>>>> the repository, Subversion encodes the previous version
>>>> (actually, several previous versions) as a delta against the new
>>>> version.
>>>>
>>>> On average, we'll be checking in 10 MB PDF or TIFF files . Will
>>>> this consume a lot of CPU or Disk I/O ? If so, how much ?
>>>
>>> Only BDB repositories do this. FSFS repositories do not do this.
>>
>> now i'm confused. for FSFS repositories what is the sequence of
>> operations for large binary files? i thought it was:
>
> The behavior is identical for binary and text files. Subversion
> sees them no differently.
>
>> 1) compare new version to previous version held in the working
>> area, generate delta
>> 2) transfer binary delta to repos and store
>
> When you commit changes, yes, a delta against the pristine copy in
> the working copy is computed and sent to the server, regardless of
> repository type. (The working copy on the client does not know or
> care how the repository is stored on the server). How the data is
> subsequently stored in the repository differs based on repository
> type. BDB stores the complete current version and rewrites the
> previous revisions to be deltas against the current revision. FSFS
> on the other hand stores a delta against some previous revision
> based on some algorithm.
can anyone explain why we need a binary diff at the repos? what is
the algorithm for determining which previous revision is diffed for
the FSFS repos delta? it seems like this is redundant
>
> I understand that Subversion has a good binary delta algorithm and
> that it is used for all files, text or binary, and that
> improvements in the algorithm are certainly welcomed.
>
reducing redundant delta calculation would be the first step here.
----- Message from "Garrett Rooney" <rooneg@electricjellyfish.net> on Wed,
24 May 2006 13:15:14 -0700 -----
To: "Simon Butler" <simon@icmethods.com>
cc: "Ryan Schmidt" <subversion-2006q2@ryandesign.com>, "Sinang, Danny"
<D.Sinang@spi-bpo.com>, users@subversion.tigris.org
Subj Re: CPU usage during commits
ect:
On 5/24/06, Simon Butler <simon@icmethods.com> wrote:
> can anyone explain why we need a binary diff at the repos? what is
> the algorithm for determining which previous revision is diffed for
> the FSFS repos delta? it seems like this is redundant
http://svn.collab.net/repos/svn/trunk/notes/skip-deltas
-garrett
----- Message from "Sinang, Danny" <D.Sinang@spi-bpo.com> on Wed, 24 May
2006 22:17:22 +0800 -----
To: <users@subversion.tigris.org>
Subject: FSFS / svn client time outs
The svn redbook says :
FSFS also has a longer delay when finalizing a commit, which could in
extreme cases cause clients to time out when waiting for a response.
What would these extreme cases be ?
Would this extreme case cause other users / clients to lock-up or time-out
as well ?
- Danny
----- Message from "George Georgalis" <george@galis.org> on Wed, 24 May
2006 12:53:00 -0400 -----
To: users@subversion.tigris.org
Subject: ...is not a working copy directory
My repo seems okay, as is a checkout local to the repo.
But for a remote checkout (file auth, svn+ssh) I'm getting
% svn cleanup www/vhost/domain.com/htdoc/
svn: 'www/vhost/domain.com/htdoc/archive/_notes' is not a working copy
directory
even after removing
<entry
name="_notes"
kind="dir"/>
from www/vhost/domain.com/htdoc/.svn/entries
I still get the error...
% svn unlock www/vhost/domain.com/htdoc/archive
svn: Working copy '/Users/geo/sub-metrg/www/vhost/domain.com/htdoc' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
details)
and I've restored that .svn/entries entry and tried many other
repairs, always get one of the two errors above; ....so, what's
next to get a clean checkout on the remote? I could blow away the
checkout, but would like to avoid a new checkout because it is
big.
// George
--
George Georgalis, systems architect, administrator <IXOYE><
http://galis.org/ cell:646-331-2027 mailto:george_at_galis.org
----- Message from "George Georgalis" <george@galis.org> on Wed, 24 May
2006 13:02:09 -0400 -----
To: users@subversion.tigris.org
Subject: Re: ...is not a working copy directory
On Wed, May 24, 2006 at 12:53:00PM -0400, George Georgalis wrote:
>My repo seems okay, as is a checkout local to the repo.
>But for a remote checkout (file auth, svn+ssh) I'm getting
>
> % svn cleanup www/vhost/domain.com/htdoc/
>svn: 'www/vhost/domain.com/htdoc/archive/_notes' is not a working copy
directory
well, this worked....
% rm -rf `find . -name _notes`
% svn cleanup
% svn up
but I have no idea how it got broke in the first place...
// George
--
George Georgalis, systems architect, administrator <IXOYE><
http://galis.org/ cell:646-331-2027 mailto:george_at_galis.org
----- Message from "Trevor Whitlock" <twhitlock@gmail.com> on Wed, 24 May
2006 11:28:22 -0600 -----
To: "George Georgalis" <george@galis.org>
cc: users@subversion.tigris.org
Subject: Re: ...is not a working copy directory
It sounds like the _notes directory did not have a .svn directory under it.
That's the reason that I have had this issue before.
-Trevor
On 5/24/06, George Georgalis <george@galis.org> wrote:
On Wed, May 24, 2006 at 12:53:00PM -0400, George Georgalis wrote:
>My repo seems okay, as is a checkout local to the repo.
>But for a remote checkout (file auth, svn+ssh) I'm getting
>
> % svn cleanup www/vhost/domain.com/htdoc/
>svn: 'www/vhost/domain.com/htdoc/archive/_notes' is not a working copy
directory
well, this worked....
% rm -rf `find . -name _notes`
% svn cleanup
% svn up
but I have no idea how it got broke in the first place...
// George
--
George Georgalis, systems architect, administrator <IXOYE><
http://galis.org/ cell:646-331-2027 mailto:george_at_galis.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
----- Message from Blair Zajac <blair@orcaware.com> on Wed, 24 May 2006
11:19:48 -0700 -----
To: Giovanni Bajo <rasky@develer.com>
cc: Dirk Schenkewitz <schenkewitz@docomolab-euro.com>,
users@subversion.tigris.org, Ryan Schmidt
<subversion-2006q2@ryandesign.com>
Subj Re: Recover after HD crash (SVN with FSFS backend)
ect:
Giovanni Bajo wrote:
> Dirk Schenkewitz wrote:
>
>
>>>Say you restored up to r100 from the backups. All the working copies
>>>after r100 are doomed. If you have three working copies pointing at
>>>r120, r140 and r160, you should first collect them from the users,
>>>then restore them with the trick you suggested (checkout, copy all
>>>the files over, commit) *and* adding padding (blank) commits into
>>>the repository so that r120 in the server actually matches the
>>>text-base version of the r120 repository, and so on for all three of
>>>them. Now think if you 500 working copies around.
>>
>>Right - without padding/"empty" versions, r120 becomes r101, r140
>>becomes r102 and so on. But since the intermediate versions are lost
>>anyway, why not live with the new revision numbers?
>
>
> Because the working copies contains the original version number! The
working
> copy that points at r120 expects that r120 on the server reflects *its*
> text-base version. If I commit what-used-to-be r140 as r101 and so on,
the
> new r120 will be totally different from what the old working copy was
> expecting. When the user runs update, the client will tell the server
"hey
> I'm revision r120, send me deltas", and the server will send deltas
between
> the *new* r120 and HEAD! The client will then try to apply those deltas
to
> *its* r120, and that won't simply work out. And what's worse, as I said
> below, is that this will probably result in some weird error client-side,
> which the user won't understand.
>
>
>
>>>The net result is that now I have a post-commit hook which dumps and
>>>backups a revision as soon as it is committed. I believe that any
>>>other backup strategy for a SVN server (say, hotcopy once a day)
>>>is basically useless.
>>
>>I have something similar, a script that runs as cron-job every 10
>>minutes and checks if something changed, if yes, it makes a hotcopy.
>
>
> I believe that there *ought* be a way to hot-rsync a Subversion server. I
> didn't investigate what hotcopy exactly does, but maybe it can be
repdoced
> with a simple script which runs rsync instead of copy. That would save
some
> performance and allow it to be done after each commit even on very busy
> servers.
Take a look at
http://svn.collab.net/repos/svn/trunk/contrib/server-side/svn-fast-backup
It's my favorite hot backup system, assuming you have a Unix OS and an FSFS
repository. It does the fastest backups, faster than svnadmin hotcopy,
since it
uses rsync's --link-dest option to hard link your latest backup to the
previous
revisions backup, 99% of the files are unchanged.
It does require subprocess, which only comes with Python 2.4.
After doing the hot backup to a local filesystem using svn-fast-backup, I
would
recommend doing an rsync of the directory containing the hot backups to
another
box so you have the repository on more than one disk, making sure to use -H
so
that rsync preserves hardlinks. Do not just rsync the new hotbackup to a
new
box, as then you'll loose the hardlinks between hot backups at different
revisions.
Regards,
Blair
--
Blair Zajac, Ph.D.
<blair@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
----- Message from ilmars.katajs-paeglis@chase.com on Wed, 24 May 2006
14:50:34 -0400 -----
To: Michael Eager <eager@eagercon.com>
cc: users@subversion.tigris.org
Subject: Re: ranlib: command not found - Subversion1.3.1 Make install on Solaris9
Thanks Michael,
I installed GNU Binutils. In fact I have two ranlib on the system now.
GNU Binutil: located in /opt/sfw/sparc-sun-solaris2.9/bin-
and Solaris native: /usr/ccs/bin/ranlib
Unfortunately, make install still fails w/ ranlib cannot find error. How do
I create .configure/make file that it points to proper ranlib?
error follows:
ln: cannot create libapr-0.so: File exists
chmod +x /usr/local/apr/lib/libapr-0.so.0.9.7
cp .libs/libapr-0.lai /usr/local/apr/lib/libapr-0.la
cp .libs/libapr-0.a /usr/local/apr/lib/libapr-0.a
ranlib /usr/local/apr/lib/libapr-0.a
/download/sas/sourcecd/subversion-1.3.1/apr/libtool: ranlib: command not
found
make[1]: *** [install] Error 127
make[1]: Leaving directory `/export/download/sas/sourcecd/subversion-1.3.1
/apr'
make: *** [external-install] Error 1
thanks.
Ilmars
--
DISCLAIMER:
This e-mail contains proprietary information some or all of which may be
legally privileged. It is for the intended recipient only. If an addressing
or transmission error has misdirected this e-mail, please notify the author
by replying to this e-mail. If you are not the intended recipient you must
not use, disclose, distribute, copy, print, or rely on this e-mail.
Received on Fri Jun 2 15:41:06 2006