Cherry-picking merges
Hi, I know, this is maybe not the best practice, but, unfortunately, our subversion users do this all the time: they merge form one branch to another back and forward. The question is, how to properly do it without introducing conflicts. Here is the test case, which one would think should be handled properly, but for some reason it's not: [~]$ svnadmin create mergerepo [~]$ svn co file://`pwd`/mergerepo mergework Checked out revision 0. [mergework]$ svn mkdir --parents branches/b1 A /home/vvc/mergework/branches A /home/vvc/mergework/branches/b1 [mergework]$ svn commit -m "Created branch b1" Adding branches Adding branches/b1 Committed revision 1. [mergework]$ svn copy branches/b1 branches/b2 A branches/b2 [mergework]$ svn commit -m "Created branch b2" Adding branches/b2 Committed revision 2. [b2]$ touch README [b2]$ svn add README A README [b2]$ svn commit -m "Added README" Adding b2/README Transmitting file data . Committed revision 3. [b1]$ svn merge -c 3 ^/branches/b2 --- Merging r3 into '.': AREADME [b1]$ svn commit -m "Merged r3 into b1" Sendingb1 Adding b1/README Committed revision 4. [b2]$ svn merge --dry-run ^/branches/b1 --- Merging r2 through r4 into '.': C README Summary of conflicts: Tree conflicts: 1 Thanks, Sincerely, Vadym Chepkov
Re: Cherry-picking merges
On Apr 29, 2010, at 3:47 AM, Daniel Becroft wrote: > > [b2]$ svn merge --dry-run ^/branches/b1 > --- Merging r2 through r4 into '.': >C README > Summary of conflicts: > Tree conflicts: 1 > > > After r3, you'll need to do a '--record-only' merge of r4 into the second > branch: > > (untested) svn merge --record-only -c 4 ^/branches/b1 > > SVN doesn't seem to trace back through the commits to see that r3 was really > a merge from b2->b1. Like yourself, I initially though that it would be able > to deal with this, but it doesn't seem to (and there is probably a very good > reason why it can't). > > Cheers, > Daniel B. Well, as you can see in the log, it also wants to merge r3 back, not just r4, so we would have to "record-only" 2 of them, it seems. The problem is, we utilize a "home made" automerge utility that constantly merges all changes from b1 to b2, but merges from b2 to b1 are done manually. After r4 is committed, it produces conflict for automerge immediately and this is what I am trying to avoid. By the way, maybe there is an intelligent automerge utility out there that can handle this kind of things, if anyone knows. Thanks, Vadym
Re: Cherry-picking merges
> [b2]$ svn merge --dry-run ^/branches/b1 > --- Merging r2 through r4 into '.': >C README > Summary of conflicts: > Tree conflicts: 1 and yet another strange thing about it. There is no way to automatically resolve a conflict like this. no matter what flag I use --accept mine-conflict, mine-full, nothing seems to make merge operation happy. I have to issue a separate svn resolve --accept working command afterwards. Vadym
Update of missing on non-working directory
Hi, I think the exit code subversion returns isn't right, it should indicate an error $ svn --version svn, version 1.6.11 (r934486) $ svn update /blah-blah Skipped '/blah-blah' $ echo $? 0 $ svn update /etc Skipped '/etc' $ echo $? 0 Vadym
Re: Update of missing on non-working directory
Consider this: $ svn -q --non-interactive update /blah-blah $ echo $? 0 No output even to stderr, no indication of a failure at all. Subversion doesn't always used interactively, hence --non-interactive switch. If you made a mistake in a script it will be unnoticed (well, this was my unpleasant surprise) Vadym On May 12, 2010, at 9:28 AM, Andy Levy wrote: > On Wed, May 12, 2010 at 09:23, Vadym Chepkov wrote: >> Hi, >> >> I think the exit code subversion returns isn't right, it should indicate an >> error >> >> $ svn --version >> svn, version 1.6.11 (r934486) >> >> >> $ svn update /blah-blah >> Skipped '/blah-blah' >> $ echo $? >> 0 >> >> $ svn update /etc >> Skipped '/etc' >> $ echo $? >> 0 > > Why? The command executed successfully and reported what it did. > Skipping something which is not a working copy isn't a program error; > attempting to update a something which is not a WC is a user error.
Re: Update of missing on non-working directory
On May 13, 2010, at 5:43 AM, Campbell Allan wrote: > > On Wednesday 12 May 2010, Vadym Chepkov wrote: >> Consider this: >> >> $ svn -q --non-interactive update /blah-blah >> $ echo $? >> 0 >> >> No output even to stderr, no indication of a failure at all. >> Subversion doesn't always used interactively, hence --non-interactive >> switch. If you made a mistake in a script it will be unnoticed (well, this >> was my unpleasant surprise) >> >> Vadym >> > > If you are using it in a script and want to guard against user error then one > of the first checks should be a svn info to verify that the path is part of a > working copy. This will return non zero on an error as well as some output > even with --non-interactive flag. > > $ svn --non-interactive info /bob > svn: '/' is not a working copy > svn: Can't open file '/.svn/entries': No such file or directory > $ echo $? > 1 > > Campbell > > p.s. try to avoid top posting on mailing lists. It makes it more difficult to > follow the chain of replies, especially when viewed online or in digests. > There are always workarounds and this is exactly what I did, but it's not "Unix" way of handling errors. Vadym
svnsync 1.8.0 fails if htdigest authentication is used
Hi, After I upgraded to 1.8.0, svnsync process started to fail. I am using apache 2.2.3. I suspect it's really serf's problem (1.2.1), but nevertheless I had to revert back to 1.7.10. Is this a known limitation? Thanks, Vadym
Re: svnsync 1.8.0 fails if htdigest authentication is used
On Jun 30, 2013, at 2:18 PM, Ryan Schmidt wrote: > > On Jun 30, 2013, at 07:06, Vadym Chepkov wrote: > >> After I upgraded to 1.8.0, svnsync process started to fail. I am using >> apache 2.2.3. I suspect it's really serf's problem (1.2.1), but nevertheless >> I had to revert back to 1.7.10. Is this a known limitation? > > You said you upgraded to 1.8.0. Was that the computer running svnsync, or the > server serving the original repository, or both? > > What error message did you get? Both source and destination run under Linux. Authentication fails, I see 401 in the apache's access log.
Re: svnsync 1.8.0 fails if htdigest authentication is used
Bert,
I would be happy to provide debugging information, but as I said, I had to
rollback to 1.7.10.
If I ran it interactively, authentication just didn't go through, so it
looked like the username or password is incorrect.
After I reverted back to 1.7.10 everything works as expected.
svnsync is called from a hook on the master server :
#!/bin/ksh
REPOS=`basename $1`
TMPFILE=/var/tmp/svnsync.$$
/usr/bin/svnsync sync --non-interactive --quiet \
--sync-username svnsync http://example.com/reposync/${REPOS} > $TMPFILE 2>&1
if [[ $? -ne 0 && -s $TMPFILE ]] ; then
mail -s "svnsync failed" root < $TMPFILE
fi
rm -f $TMPFILE
exit 0
Slave server is properly initialized:
sudo -u apache svn pg svn:sync-from-url --revprop -r 0 --username svnsync
http://example.com/reposync/repo1
http://example.com/svn/repo1
I was receiving errors like this in e-mail:
svnsync: E175002: Unable to connect to a repository at URL '
http://example.com/reposync/repo1'
svnsync: E175002: OPTIONS of 'http://example.com/reposync/repo1': could not
connect to server (http://example.com)
or this
svnsync: E175002: PROPFIND of '/reposync/repo2/!svn/rev/0': could not
connect to server (http://example.com)
Regards,
Vadym
On Mon, Jul 1, 2013 at 12:07 PM, Bert Huijben wrote:
>
>
> > -Original Message-
> > From: Vadym Chepkov [mailto:vchep...@gmail.com]
> > Sent: zondag 30 juni 2013 22:58
> > To: Ryan Schmidt
> > Cc: users@subversion.apache.org
> > Subject: Re: svnsync 1.8.0 fails if htdigest authentication is used
> >
> >
> > On Jun 30, 2013, at 2:18 PM, Ryan Schmidt wrote:
> >
> > >
> > > On Jun 30, 2013, at 07:06, Vadym Chepkov wrote:
> > >
> > >> After I upgraded to 1.8.0, svnsync process started to fail. I am using
> > apache 2.2.3. I suspect it's really serf's problem (1.2.1), but
> nevertheless I had
> > to revert back to 1.7.10. Is this a known limitation?
> > >
> > > You said you upgraded to 1.8.0. Was that the computer running svnsync,
> or
> > the server serving the original repository, or both?
> > >
> > > What error message did you get?
> >
> >
> > Both source and destination run under Linux. Authentication fails, I see
> 401 in
> > the apache's access log.
> >
>
> Hi,
>
> I expected a problem related to some recent fixes in serf that should be
> available in the next release, but one of the serf developers ensured me
> that it was not this problem.
>
> <@lgo> Bert: serf 1.2.1 fixed an issue with htdigest, no server
> authentication issues are known.
> <@lgo> I have no problem syncing a repository on a server using digest
> either
> <@lgo> that is, from a repository over ra_serf with digest authn to
> ra_local.
> <@lgo> The thread on users doesn't contain a lot of info, and I'm not
> subscribed to users. So if you can get some more info about his setup,
> exact
> error message, whether that's directly or after a while ... I will look
> into
> it further.
>
> So I would repeat Ryan's request. Can you show us what goes wrong (with
> what
> error) and how we can reproduce this problem?
>
> It is quite interesting to know if this happens directly at the start or
> after a huge chunk of work was completed.
>
> Bert
>
>
Re: svnsync 1.8.0 fails if htdigest authentication is used
Bert,
Master had KeepAlive on, replica - KeepAlive Off
On Tue, Jul 2, 2013 at 3:32 PM, Bert Huijben wrote:
> Hi Vadym,
>
> ** **
>
> We found a related issue while testing the serf http code, which might be
> related to your issue.
>
> ** **
>
> Can you somehow check if your repository has the ‘KeepAlive’ option
> configured to off? In this case the digest code in serf performs every
> request without authentication, because it would only try to use
> authentication on later requests on the same connection
>
> ** **
>
> If that is the case, it looks like this issue will be resolved with the
> next serf release. (Which should happen with or before Subversion 1.8.1).*
> ***
>
> ** **
>
> Bert
>
> ** **
>
> [Added CC to one of the serf developers, who isn’t subscribed to this list]
>
>
> ** **
>
> *From:* Vadym Chepkov [mailto:vchep...@gmail.com]
> *Sent:* maandag 1 juli 2013 18:32
> *To:* Bert Huijben
> *Cc:* users@subversion.apache.org; Ryan Schmidt
>
> *Subject:* Re: svnsync 1.8.0 fails if htdigest authentication is used
>
> ** **
>
> Bert,
>
> ** **
>
> I would be happy to provide debugging information, but as I said, I had to
> rollback to 1.7.10.
>
> ** **
>
> If I ran it interactively, authentication just didn't go through, so it
> looked like the username or password is incorrect.
>
> After I reverted back to 1.7.10 everything works as expected.
>
> ** **
>
> svnsync is called from a hook on the master server :
>
> ** **
>
> #!/bin/ksh
>
> REPOS=`basename $1`
>
> TMPFILE=/var/tmp/svnsync.$$
>
> /usr/bin/svnsync sync --non-interactive --quiet \
>
> --sync-username svnsync http://example.com/reposync/${REPOS} > $TMPFILE
> 2>&1
>
> if [[ $? -ne 0 && -s $TMPFILE ]] ; then
>
> mail -s "svnsync failed" root < $TMPFILE
>
> fi
>
> rm -f $TMPFILE
>
> exit 0
>
> ** **
>
> Slave server is properly initialized:
>
> ** **
>
> sudo -u apache svn pg svn:sync-from-url --revprop -r 0 --username
> svnsync http://example.com/reposync/repo1
>
> ** **
>
> http://example.com/svn/repo1
>
> ** **
>
> ** **
>
> I was receiving errors like this in e-mail:
>
> ** **
>
> svnsync: E175002: Unable to connect to a repository at URL '
> http://example.com/reposync/repo1'
> svnsync: E175002: OPTIONS of 'http://example.com/reposync/repo1': could
> not connect to server (http://example.com)
>
> ** **
>
> or this
>
> ** **
>
> svnsync: E175002: PROPFIND of '/reposync/repo2/!svn/rev/0': could not
> connect to server (http://example.com)
>
> ** **
>
> ** **
>
> Regards,
>
> Vadym
>
> ** **
>
> ** **
>
> On Mon, Jul 1, 2013 at 12:07 PM, Bert Huijben wrote:
>
>
>
> > -Original Message-
> > From: Vadym Chepkov [mailto:vchep...@gmail.com]
> > Sent: zondag 30 juni 2013 22:58
> > To: Ryan Schmidt
> > Cc: users@subversion.apache.org
> > Subject: Re: svnsync 1.8.0 fails if htdigest authentication is used
> >
> >
> > On Jun 30, 2013, at 2:18 PM, Ryan Schmidt wrote:
> >
> > >
> > > On Jun 30, 2013, at 07:06, Vadym Chepkov wrote:
> > >
> > >> After I upgraded to 1.8.0, svnsync process started to fail. I am using
> > apache 2.2.3. I suspect it's really serf's problem (1.2.1), but
> nevertheless I had
> > to revert back to 1.7.10. Is this a known limitation?
> > >
> > > You said you upgraded to 1.8.0. Was that the computer running svnsync,
> or
> > the server serving the original repository, or both?
> > >
> > > What error message did you get?
> >
> >
> > Both source and destination run under Linux. Authentication fails, I see
> 401 in
> > the apache's access log.
> >
>
> Hi,
>
> I expected a problem related to some recent fixes in serf that should be
> available in the next release, but one of the serf developers ensured me
> that it was not this problem.
>
> <@lgo> Bert: serf 1.2.1 fixed an issue with htdigest, no server
> authentication issues are known.
> <@lgo> I have no problem syncing a repository on a server using digest
> either
> <@lgo> that is, from a repository over ra_serf with digest authn to
> ra_local.
> <@lgo> The thread on users doesn't contain a lot of info, and I'm not
> subscribed to users. So if you can get some more info about his setup,
> exact
> error message, whether that's directly or after a while ... I will look
> into
> it further.
>
> So I would repeat Ryan's request. Can you show us what goes wrong (with
> what
> error) and how we can reproduce this problem?
>
> It is quite interesting to know if this happens directly at the start or
> after a huge chunk of work was completed.
>
> Bert
>
> ** **
>
Re: svnsync 1.8.0 fails if htdigest authentication is used
I will change it, thank you, but I should mention, KeepAlive is off by
default on Redhat EL/Fedora and derivatives.
On Tue, Jul 2, 2013 at 3:50 PM, Lieven Govaerts wrote:
> Hi,
>
> On Tue, Jul 2, 2013 at 9:38 PM, Vadym Chepkov wrote:
> > Bert,
> >
> > Master had KeepAlive on, replica - KeepAlive Off
> >
>
> as Bert said, Digest authentication to servers configured with
> KeepAlive Off is currently broken in serf 1.2.1, the version used in
> svn 1.8.0.
> I have a patch that fixes this, as soon as I finish the unit test I'll
> commit to serf trunk and make sure it gets included in serf 1.3.0.
>
> Now, I can only advise you to always use KeepAlive On for the server
> hosting your Subversion repositories. Svn will make many (small)
> requests to the server, and in your configuration a new TCP connection
> is opened for every request. I've noticed svnsync performing much
> slower with KeepAlive Off.
>
> Lieven
>
> >
> > On Tue, Jul 2, 2013 at 3:32 PM, Bert Huijben wrote:
> >>
> >> Hi Vadym,
> >>
> >>
> >>
> >> We found a related issue while testing the serf http code, which might
> be
> >> related to your issue.
> >>
> >>
> >>
> >> Can you somehow check if your repository has the ‘KeepAlive’ option
> >> configured to off? In this case the digest code in serf performs every
> >> request without authentication, because it would only try to use
> >> authentication on later requests on the same connection
> >>
> >>
> >>
> >> If that is the case, it looks like this issue will be resolved with the
> >> next serf release. (Which should happen with or before Subversion
> 1.8.1).
> >>
> >>
> >>
> >> Bert
> >>
> >>
> >>
> >> [Added CC to one of the serf developers, who isn’t subscribed to this
> >> list]
> >>
> >>
> >>
> >> From: Vadym Chepkov [mailto:vchep...@gmail.com]
> >> Sent: maandag 1 juli 2013 18:32
> >> To: Bert Huijben
> >> Cc: users@subversion.apache.org; Ryan Schmidt
> >>
> >>
> >> Subject: Re: svnsync 1.8.0 fails if htdigest authentication is used
> >>
> >>
> >>
> >> Bert,
> >>
> >>
> >>
> >> I would be happy to provide debugging information, but as I said, I had
> to
> >> rollback to 1.7.10.
> >>
> >>
> >>
> >> If I ran it interactively, authentication just didn't go through, so it
> >> looked like the username or password is incorrect.
> >>
> >> After I reverted back to 1.7.10 everything works as expected.
> >>
> >>
> >>
> >> svnsync is called from a hook on the master server :
> >>
> >>
> >>
> >> #!/bin/ksh
> >>
> >> REPOS=`basename $1`
> >>
> >> TMPFILE=/var/tmp/svnsync.$$
> >>
> >> /usr/bin/svnsync sync --non-interactive --quiet \
> >>
> >> --sync-username svnsync http://example.com/reposync/${REPOS} > $TMPFILE
> >> 2>&1
> >>
> >> if [[ $? -ne 0 && -s $TMPFILE ]] ; then
> >>
> >> mail -s "svnsync failed" root < $TMPFILE
> >>
> >> fi
> >>
> >> rm -f $TMPFILE
> >>
> >> exit 0
> >>
> >>
> >>
> >> Slave server is properly initialized:
> >>
> >>
> >>
> >> sudo -u apache svn pg svn:sync-from-url --revprop -r 0 --username
> >> svnsync http://example.com/reposync/repo1
> >>
> >>
> >>
> >> http://example.com/svn/repo1
> >>
> >>
> >>
> >>
> >>
> >> I was receiving errors like this in e-mail:
> >>
> >>
> >>
> >> svnsync: E175002: Unable to connect to a repository at URL
> >> 'http://example.com/reposync/repo1'
> >> svnsync: E175002: OPTIONS of 'http://example.com/reposync/repo1': could
> >> not connect to server (http://example.com)
> >>
> >>
> >>
> >> or this
> >>
> >>
> >>
> >> svnsync: E175002: PROPFIND of '/reposync/repo2/!svn/rev/0': could not
> >> connect to server (http://example.com)
> >>
> >>
> >>
> >>
> >>
> >> Regards,
> >>
> >> Vadym
> >>
> >>
> >>
>
