You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Summers <da...@summersoft.fay.ar.us> on 2008/04/28 20:38:07 UTC
New SVNSYNC bug?
I've been using 1.5.0 SVNSYNC with WEBDAV proxy since about three days
after the feature was committed in 2006/12 and have had very few problems with
it. Master: 1.4.2 (Win2KR3), Slave: 1.5.0 (RHEL5) (web dav proxy enabled).
The last stable version I've been using was r27613 from Nov 2007/11.
A week or so ago I upgraded to 1.5.0 rc3.
Today I was doing some tags and I noticed that the SVNSYNC didn't seem to
be working, I wasn't getting the new versions into the mirror repository.
That happens evry once in a while and I have to manually do the SVNSYNC
but it normally only happens on big commits.
I ran the SVNSYNC manually and it claimed it transferred over the new
revision. I went to the mirror repository and checked and it showed a new
revision but the "svn log -v" showed the Changed Paths as blank and no
commit log message.
I puzzled about that for a few minutes and decided to try to re-initialize
and re-sync the (small 25 revision) repository where the error showed up.
I have a script file which sets up my mirror repositories with
"svnadmin" and "svnsync init" and saved the old mirror and ran the script to
(re)create the new one.
I then ran svnsync on the master like I normally do to populate a new
mirror after initialization with "svnadmin" and "svnsync init".
Now ALL 25 revs showed up with no paths and no messages.
Currently I'm working around the problem by manually copying db/revs and
db/revprops. I've noticed that the mirror version of the
db/reprops/X after svnsync only has "END" in it and both the db/revs/X and
db/revprops/X files don't seem to match the file length of those files on the
master server.
Once I copy the files manually from master to slave it looks like
everything is OK.
If I were guessing, I would guess something to do with SVNSYNC has
regressed sometime between r27613 from last 2007/11 to RC3 as of a couple
of weeks ago?
I will now proceed to attempt to downgrade back to r27613 and see if the
problem goes away.
Any ideas? If I can provide any more information, please let me know. I
doubt I can provide the repo to any one for looking at but if you think it
is important I can ask my supervisor.
Thanks!
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = 0B44 B118 85CC F4EC 7021 1ED4 1516 5B78 E320 2001
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New SVNSYNC bug?
Posted by David Glasser <gl...@davidglasser.net>.
OK, hmm. To clarify: you originally discovered this using webdav
proxy, but you then were able to reproduce it with a script using
svnsync manually, without using the webdav proxy feature at all? And
what RA layers/libraries did you use for the svnsync run?
--dave
On Mon, Apr 28, 2008 at 2:10 PM, David Summers
<da...@summersoft.fay.ar.us> wrote:
>
> David Glasser asked me to clarify some things:
>
> My current version number on the RHEL5 slave web-dav enabled server is:
> 1.5.0-rc4 (I upgraded from rc3 to rc4 and tested before sending email about
> the problem).
>
> My current version number on the Win2003 master server is: 1.4.2
>
> My current version number on my client is: 1.4.6 (On WinXP SP2).
> (Also TortiseSVN 1.4.8 - Subversion 1.4.6)
>
> Hope that helps.
>
> - Thanks!
> - David Summers
>
>
> On Mon, Apr 28, 2008 at 1:38 PM, David Summers
> <da...@summersoft.fay.ar.us> wrote:
>
> >
> > I've been using 1.5.0 SVNSYNC with WEBDAV proxy since about three days
> > after the feature was committed in 2006/12 and have had very few
> >
> problems
>
> > with
> > it. Master: 1.4.2 (Win2KR3), Slave: 1.5.0 (RHEL5) (web dav proxy
> >
> enabled).
>
> >
> > The last stable version I've been using was r27613 from Nov 2007/11.
> >
> > A week or so ago I upgraded to 1.5.0 rc3.
> >
>
> Just to clarify, can you give precise version numbers for the master
> and slave servers now *and your client*?
>
> Thanks,
> dave
>
>
>
> > Today I was doing some tags and I noticed that the SVNSYNC didn't seem
> >
> to
>
> > be working, I wasn't getting the new versions into the mirror
> >
> repository.
>
> >
> > That happens evry once in a while and I have to manually do the SVNSYNC
> >
> but
>
> > it normally only happens on big commits.
> >
> > I ran the SVNSYNC manually and it claimed it transferred over the new
> > revision. I went to the mirror repository and checked and it showed a
> >
> new
>
> > revision but the "svn log -v" showed the Changed Paths as blank and no
> > commit log message.
> >
> > I puzzled about that for a few minutes and decided to try to
> >
> re-initialize
>
> > and re-sync the (small 25 revision) repository where the error showed
> >
> up.
>
> >
> > I have a script file which sets up my mirror repositories with
> >
> "svnadmin"
>
> > and "svnsync init" and saved the old mirror and ran the script to
> > (re)create the new one.
> >
> > I then ran svnsync on the master like I normally do to populate a new
> > mirror after initialization with "svnadmin" and "svnsync init".
> >
> > Now ALL 25 revs showed up with no paths and no messages.
> >
> > Currently I'm working around the problem by manually copying db/revs
> >
> and
>
> > db/revprops. I've noticed that the mirror version of the db/reprops/X
> >
> after
>
> > svnsync only has "END" in it and both the db/revs/X and
> > db/revprops/X files don't seem to match the file length of those files
> >
> on
>
> > the
> > master server.
> >
> > Once I copy the files manually from master to slave it looks like
> > everything is OK.
> >
> > If I were guessing, I would guess something to do with SVNSYNC has
> > regressed sometime between r27613 from last 2007/11 to RC3 as of a
> >
> couple of
>
> > weeks ago?
> >
> > I will now proceed to attempt to downgrade back to r27613 and see if
> >
> the
>
> > problem goes away.
> >
> > Any ideas? If I can provide any more information, please let me know.
> >
> I
>
> > doubt I can provide the repo to any one for looking at but if you think
> >
> it
>
> > is important I can ask my supervisor.
> >
> > Thanks!
> >
> > --
> > David Wayne Summers "Linux: Because reboots are for hardware
> > upgrades!"
> > david@summersoft.fay.ar.us PGP Key:
> > http://summersoft.fay.ar.us/~david/pgp.txt
> > PGP Key fingerprint = 0B44 B118 85CC F4EC 7021 1ED4 1516 5B78 E320
> >
> 2001
>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
> >
> >
> >
>
> --
> David Wayne Summers "Linux: Because reboots are for hardware
> upgrades!"
> david@summersoft.fay.ar.us PGP Key:
> http://summersoft.fay.ar.us/~david/pgp.txt
> PGP Key fingerprint = 0B44 B118 85CC F4EC 7021 1ED4 1516 5B78 E320 2001
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New SVNSYNC bug?
Posted by David Summers <da...@summersoft.fay.ar.us>.
David Glasser asked me to clarify some things:
My current version number on the RHEL5 slave web-dav enabled server is:
1.5.0-rc4 (I upgraded from rc3 to rc4 and tested before sending email
about the problem).
My current version number on the Win2003 master server is: 1.4.2
My current version number on my client is: 1.4.6 (On WinXP SP2).
(Also TortiseSVN 1.4.8 - Subversion 1.4.6)
Hope that helps.
- Thanks!
- David Summers
On Mon, Apr 28, 2008 at 1:38 PM, David Summers
<da...@summersoft.fay.ar.us> wrote:
>
> I've been using 1.5.0 SVNSYNC with WEBDAV proxy since about three days
> after the feature was committed in 2006/12 and have had very few
problems
> with
> it. Master: 1.4.2 (Win2KR3), Slave: 1.5.0 (RHEL5) (web dav proxy
enabled).
>
> The last stable version I've been using was r27613 from Nov 2007/11.
>
> A week or so ago I upgraded to 1.5.0 rc3.
Just to clarify, can you give precise version numbers for the master
and slave servers now *and your client*?
Thanks,
dave
> Today I was doing some tags and I noticed that the SVNSYNC didn't seem
to
> be working, I wasn't getting the new versions into the mirror
repository.
>
> That happens evry once in a while and I have to manually do the SVNSYNC
but
> it normally only happens on big commits.
>
> I ran the SVNSYNC manually and it claimed it transferred over the new
> revision. I went to the mirror repository and checked and it showed a
new
> revision but the "svn log -v" showed the Changed Paths as blank and no
> commit log message.
>
> I puzzled about that for a few minutes and decided to try to
re-initialize
> and re-sync the (small 25 revision) repository where the error showed
up.
>
> I have a script file which sets up my mirror repositories with
"svnadmin"
> and "svnsync init" and saved the old mirror and ran the script to
> (re)create the new one.
>
> I then ran svnsync on the master like I normally do to populate a new
> mirror after initialization with "svnadmin" and "svnsync init".
>
> Now ALL 25 revs showed up with no paths and no messages.
>
> Currently I'm working around the problem by manually copying db/revs
and
> db/revprops. I've noticed that the mirror version of the db/reprops/X
after
> svnsync only has "END" in it and both the db/revs/X and
> db/revprops/X files don't seem to match the file length of those files
on
> the
> master server.
>
> Once I copy the files manually from master to slave it looks like
> everything is OK.
>
> If I were guessing, I would guess something to do with SVNSYNC has
> regressed sometime between r27613 from last 2007/11 to RC3 as of a
couple of
> weeks ago?
>
> I will now proceed to attempt to downgrade back to r27613 and see if
the
> problem goes away.
>
> Any ideas? If I can provide any more information, please let me know.
I
> doubt I can provide the repo to any one for looking at but if you think
it
> is important I can ask my supervisor.
>
> Thanks!
>
> --
> David Wayne Summers "Linux: Because reboots are for hardware
> upgrades!"
> david@summersoft.fay.ar.us PGP Key:
> http://summersoft.fay.ar.us/~david/pgp.txt
> PGP Key fingerprint = 0B44 B118 85CC F4EC 7021 1ED4 1516 5B78 E320
2001
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = 0B44 B118 85CC F4EC 7021 1ED4 1516 5B78 E320 2001
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New SVNSYNC bug?
Posted by David Glasser <gl...@davidglasser.net>.
On Mon, Apr 28, 2008 at 1:38 PM, David Summers
<da...@summersoft.fay.ar.us> wrote:
>
> I've been using 1.5.0 SVNSYNC with WEBDAV proxy since about three days
> after the feature was committed in 2006/12 and have had very few problems
> with
> it. Master: 1.4.2 (Win2KR3), Slave: 1.5.0 (RHEL5) (web dav proxy enabled).
>
> The last stable version I've been using was r27613 from Nov 2007/11.
>
> A week or so ago I upgraded to 1.5.0 rc3.
Just to clarify, can you give precise version numbers for the master
and slave servers now *and your client*?
Thanks,
dave
> Today I was doing some tags and I noticed that the SVNSYNC didn't seem to
> be working, I wasn't getting the new versions into the mirror repository.
>
> That happens evry once in a while and I have to manually do the SVNSYNC but
> it normally only happens on big commits.
>
> I ran the SVNSYNC manually and it claimed it transferred over the new
> revision. I went to the mirror repository and checked and it showed a new
> revision but the "svn log -v" showed the Changed Paths as blank and no
> commit log message.
>
> I puzzled about that for a few minutes and decided to try to re-initialize
> and re-sync the (small 25 revision) repository where the error showed up.
>
> I have a script file which sets up my mirror repositories with "svnadmin"
> and "svnsync init" and saved the old mirror and ran the script to
> (re)create the new one.
>
> I then ran svnsync on the master like I normally do to populate a new
> mirror after initialization with "svnadmin" and "svnsync init".
>
> Now ALL 25 revs showed up with no paths and no messages.
>
> Currently I'm working around the problem by manually copying db/revs and
> db/revprops. I've noticed that the mirror version of the db/reprops/X after
> svnsync only has "END" in it and both the db/revs/X and
> db/revprops/X files don't seem to match the file length of those files on
> the
> master server.
>
> Once I copy the files manually from master to slave it looks like
> everything is OK.
>
> If I were guessing, I would guess something to do with SVNSYNC has
> regressed sometime between r27613 from last 2007/11 to RC3 as of a couple of
> weeks ago?
>
> I will now proceed to attempt to downgrade back to r27613 and see if the
> problem goes away.
>
> Any ideas? If I can provide any more information, please let me know. I
> doubt I can provide the repo to any one for looking at but if you think it
> is important I can ask my supervisor.
>
> Thanks!
>
> --
> David Wayne Summers "Linux: Because reboots are for hardware
> upgrades!"
> david@summersoft.fay.ar.us PGP Key:
> http://summersoft.fay.ar.us/~david/pgp.txt
> PGP Key fingerprint = 0B44 B118 85CC F4EC 7021 1ED4 1516 5B78 E320 2001
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org