Re: New SVNSYNC bug?

On Tue, Apr 29, 2008 at 4:16 PM, David Glasser <glasser_at_davidglasser.net> wrote:
>
> On Tue, Apr 29, 2008 at 12:11 PM, David Summers
> <david_at_summersoft.fay.ar.us> wrote:
> > On Tue, 29 Apr 2008, Lieven Govaerts wrote:
> >
> >
> > > Justin Erenkrantz wrote:
> > >
> > > > On Mon, Apr 28, 2008 at 3:48 PM, David Glasser
> > <glasser_at_davidglasser.net>
> > > > wrote:
> > > > > There were in fact changes to the svnsync RA calls as well as to the
> > > > > svnserve protocol for it, so I wouldn't be horribly surprised if we
> > > > > screwed something up in the compatibility code or something.
> > > >
> > > > FWIW, we're starting to deploy the mirroring code over at apache.org
> > > > and we're seeing a similar bug to what David S. is seeing: new files
> > > > aren't being added over replay. Changed/modified files are okay.
> > > >
> > > > (Sadly, our master SVN server has suffered a hard drive failure; so
> > > > this is on the back burner for us now.) -- justin
> > > >
> > > >
> > >
> > > David, Justin,
> > >
> > > For completeness sake:
> > > 1. between master and svnsync client you're using http, with ra_serf or
> > ra_neon?
> > > 2. between svnsync and slave you're using what? ra_local?
> > >
> > >
> >
> > Maybe I'm not understanding (terminology?) something, but here is my setup.
> >
> > 1. I commit from a WinXP SP2 client using Subversion command-line client
> > 1.4.6 with http method. (I commit to the web-dav proxy enabled slave but as
> > per your message above, that may not be relevant, the master is not being
> > corrupted as far as I can tell).
> >
> > 2. The master server receives the commit and in the post-commit hook does a
> > svnsync to the slave.
> >
> > 3. On the slave server I have svnserve running (svn method) to do the sync
> > between the master and slave.
> >
> > When I then subsequently check the slave server with "svn log -v" then I
> > see no information in "Changed Paths" and no log message.
> >
> > Hope that helps. I'm working on setting up a controlled test with rc3 to
> > see what happens and if I can narrow it down any further.
> >
> > When I backed the slave back down from rc3 to r27613 then things started
> > working fine again.
> >
> > Also, I'm beginning to wonder if the problem only showed up on a slave repo
> > created recently with rc3 or higher but I don't remember exactly when I
> > installed rc3 or created the new slave repo. I *think* I'm only seeing
> > corruption on my newest small repo and not ones created earlier with r27613
> > or older, but I can't swear to it yet.
>
> I'm not sure that this would be relevant, but there are a couple of
> places you are breaking our abstractions and doing things by hand:
>
>
>
> > Here is my script I use to create slave repos:
> > #! /bin/bash
> > # Set up a mirror from SAMSON
> >
> > usage() {
> > echo "Usage: setup.mirror RepositoryName
> > http://SourceHost/SourceRepository"
> > exit 1
> > }
> >
> > if [ ! -f repos/TEMPLATE/README.txt ]; then
> > echo "Missing TEMPLATE repository."
> > exit 1
> > fi
> >
> > if [ "$1"x = "x" ]; then
> > usage
> > fi
> >
> > if [ "$2"x = "x" ]; then
> > usage
> > fi
> >
> > REPO_NAME=$1
> > SOURCE_REPOSITORY=$2
> >
> > result=`echo $SOURCE_REPOSITORY | grep -i http://`
> >
> > if [ "$result"x = "x" ]; then
> > usage
> > fi
> >
> > # Create new repository
> > svnadmin --pre-1.5-compatible create repos/$REPO_NAME
> >
> > # Zap initial template files
> > rm -rf repos/$REPO_NAME/hooks/*.tmpl
> >
> > # Copy template hooks from TEMPLATE repo
> > cp repos/TEMPLATE/hooks/* repos/$REPO_NAME/hooks
> >
> > # Zap initial conf files.
> > rm -rf repos/$REPO_NAME/conf/*
> >
> > # Setup svnserve.conf
> > (cd repos/$REPO_NAME/conf; ln -s ../../../svnserve.conf .)
>
> What's in the conf?
>
> Specifically, could there be any authz issues here, where your
> svnsyncing user can't read all the files?
>
>
> > # Get UUID from source repository
> > uuid=`svn info $SOURCE_REPOSITORY | grep -i uuid | sed -e 's/^.*:\s//'`
> >
> > echo UUID = \"$uuid\"
> >
> > echo $uuid > repos/$REPO_NAME/db/uuid
>
> You can use svnadmin setuuid here now.
>
>
> > # Set up for SYNC operation
> > svnsync init file:///home/svnroot/repos/$REPO_NAME $SOURCE_REPOSITORY
> >
> > svn ps svn:sync-from-url svn://samson/$REPO_NAME
> > file:///home/svnroot/repos/$REPO_NAME -r0 --revprop --username=svnsync
>
> Why not just use the right URL with svnsync init in the first place?
>
>
> > chown -R apache:apache repos/$REPO_NAME
> >
> > exit 0
> >
> >
> > Here is my script I run on the master server to sync to the slave
> > (razorback) on post-commit.
> >
> > "C:\Program Files\Subversion\bin\svnsync" sync svn://razorback/%1%
>
> Hmm, so the master is Windows, and the slave is Unix? Interesting;
> this stuff might be undertested on Windows, though I'm not sure why it
> should make a difference.

Did you ever use this with one of the 1.5 pre-release versions before
we nailed down the repository format? The repository internals
changed a lot over time and people that used the in-between stage
binaries could definitely get weird results.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org