svnsync: Error while replaying commit

[Gary]

I see a lot of reports of this error, but little in the way of
clear information as to what it might mean, or how to fix it:

$ svnsync sync file://`pwd`/dest
Committed revision 1.
Copied properties for revision 1.
Transmitting file data .
[...]
Committed revision 79.
Copied properties for revision 79.
Transmitting file data ...
Committed revision 80.
Copied properties for revision 80.
svnsync: Error while replaying commit

Huh?

If I look at the source server log, revs 81 & 82 are "missing"
in the trunk. I imagine they are/were in a branch, which AFAIK
is no longer available. Is there any way to get around this?
Assuming that's the problem, of course.

Re: svnsync: Error while replaying commit

[Gary]

- Original Message -
From: Henrik Sundberg

> Do you have a precommit hook now that was not there when revs 81-82
were committed?
There are no hooks as far as I know. (I'm not an admin, and the admin is not 
very forthcoming on.. well, anything, really).


> Svn log will show the revisions whereever in the repository they were
> made. Are they missing for real?
Yes the revisions are really missing:
  $ svn log
  [snip]
  
  r83 | gpspbu | 2011-06-24 12:34:38 
+0200 (Fri, 24 Jun 2011) | 1 line

  added missing file
  
  r80 | gpspbu | 2011-06-23 16:23:46 
+0200 (Thu, 23 Jun 2011) | 1 line

  Added WP31
  
  r79 | gpspbu | 2011-06-23 15:58:15 
+0200 (Thu, 23 Jun 2011) | 1 line

  Added a PhoneNumberUnlocker
  



On Fri, Mar 30, 2012 at 15:25, Gary  wrote:
> I see a lot of reports of this error, but little in the way of
> clear information as to what it might mean, or how to fix it:
>
> $ svnsync sync file://`pwd`/dest
> Committed revision 1.
> Copied properties for revision 1.
> Transmitting file data .
> [...]
> Committed revision 79.
> Copied properties for revision 79.
> Transmitting file data ...
> Committed revision 80.
> Copied properties for revision 80.
> svnsync: Error while replaying commit
>
> Huh?
>
> If I look at the source server log, revs 81 & 82 are "missing"
> in the trunk. I imagine they are/were in a branch, which AFAIK
> is no longer available. Is there any way to get around this?
> Assuming that's the problem, of course.
>

Re: svnsync: Error while replaying commit

[Gary]

From: Giulio Troccoli
On 02/04/12 08:27, Gary wrote:
>> - Original Message -
>> From: Henrik Sundberg
>>
>>> Do you have a precommit hook now that was not there when revs 81-82
>> were committed?
>> There are no hooks as far as I know. (I'm not an admin, and the admin is not 
>> very forthcoming on.. well, anything, really).
>>
>>
>>> Svn log will show the revisions whereever in the repository they were
>>> made. Are they missing for real?
>> Yes the revisions are really missing:
>>    $ svn log
>
>Did you run svn log on the working copy? I ask because it's really 
>strange that two revisions are missing so maybe they have been made on a 
>different part of the repository. I would suggest running svn info to 
>get the correct repository URL and then run svn log against that URL.

Hmm. Yeah, I ran it on a working copy, just based on what Henrik said.
I wasn't really thinking (being on call will do that to a chap)... Sorry.
This is perhaps better:

$ svn log svn://devel.//
[snip]

r84 | gpspbu | 2011-06-24 12:52:16 +0200 (Fri, 24 Jun 2011) | 1 line

merged trunk to branch

r83 | gpspbu | 2011-06-24 12:34:38 +0200 (Fri, 24 Jun 2011) | 1 line

added missing file

r82 | ggapbu | 2011-06-23 17:58:49 +0200 (Thu, 23 Jun 2011) | 1 line

test

r81 | gpspbu | 2011-06-23 17:48:03 +0200 (Thu, 23 Jun 2011) | 1 line

Created a branch working of //trunk.

r80 | gpspbu | 2011-06-23 16:23:46 +0200 (Thu, 23 Jun 2011) | 1 line

Added WP31

[snip]

But that still doesn't explain to me why svnsync barfs on those (not)
missing revisions. Looking at the command line history, I can't see 

anywhere where I pointed svnsync at just the trunk, only ever at the 

repo/project within the repo (I took my instructions from
http://svn.apache.org/repos/asf/subversion/trunk/notes/svnsync.txt)



> On Fri, Mar 30, 2012 at 15:25, Gary  wrote:
>> I see a lot of reports of this error, but little in the way of
>> clear information as to what it might mean, or how to fix it:
>>
>> $ svnsync sync file://`pwd`/dest
>> Committed revision 1.
>> Copied properties for revision 1.
>> Transmitting file data .
>> [...]
>> Committed revision 79.
>> Copied properties for revision 79.
>> Transmitting file data ...
>> Committed revision 80.
>> Copied properties for revision 80.
>> svnsync: Error while replaying commit
>>
>> Huh?
>>
>> If I look at the source server log, revs 81&  82 are "missing"
>> in the trunk. I imagine they are/were in a branch, which AFAIK
>> is no longer available. Is there any way to get around this?
>> Assuming that's the problem, of course.
>>
- Original Message -

Re: svnsync: Error while replaying commit

[Gary]

From: Ulrich Eckhardt 
>> I imagine they are/were in a branch, which AFAIK is no longer
>> available. Is there any way to get around this? Assuming that's
>> the problem, of course.
>
> Do you know more about this branch and how it was removed? Just "svn
> delete"ing a branch doesn't cause revisions to vanish. I guess the
> repository was modified using the dumpfilter to remove that branch,
> causing a non-contiguous range of revisions. svnsync then chokes on
> this, because it expects the revisions to be contiguous.

See my other email, I got the svn log command wrong, and the branch
*is* still available, just can't be modified any more. The question
is, why svnsync gets its knickers into a twist about that. The
revisions *are* available (and can be checked out, I checked). The
"howto" (link in other email) makes no mention of having to do
anything special to handle repos with branches in a special way.

Re: svnsync: Error while replaying commit

[Gary]

- Original Message -
From: Giulio Troccoli
> On 02/04/12 10:24, Gary wrote:

>> This is perhaps better:
>>
>> $ svn log svn://devel.//
>> [snip]
>> 
>> r84 | gpspbu | 2011-06-24 12:52:16 +0200 (Fri, 24 Jun 2011) | 1 line
>>
>> merged trunk to branch
>> 
>> r83 | gpspbu | 2011-06-24 12:34:38 +0200 (Fri, 24 Jun 2011) | 1 line
>>
>> added missing file
>> 
>> r82 | ggapbu | 2011-06-23 17:58:49 +0200 (Thu, 23 Jun 2011) | 1 line
>>
>> test
>> 
>> r81 | gpspbu | 2011-06-23 17:48:03 +0200 (Thu, 23 Jun 2011) | 1 line
>>
>> Created a branch working of //trunk.
>> 
>> r80 | gpspbu | 2011-06-23 16:23:46 +0200 (Thu, 23 Jun 2011) | 1 line
>>
>> Added WP31
>> 
>> [snip]
>>
>> But that still doesn't explain to me why svnsync barfs on those (not)
>> missing revisions. Looking at the command line history, I can't see
>>
>> anywhere where I pointed svnsync at just the trunk, only ever at the
>>
>> repo/project within the repo (I took my instructions from
>> http://svn.apache.org/repos/asf/subversion/trunk/notes/svnsync.txt)
>>
>
>Well, at least we know that the revisions are not missing.
>
>Can you show us the source repository path for you synced repo? It 
>should be in one of the properties stored in revision 0 in the synced 
>repo, if I remember well.

Do you mean in the properties of the one I am trying to sync into, or
from?I'm not really sure what you mean :P

>Also, can you run svn log -v on revision 80, 81 and 82?

[11:41:02] jg@ggajg ~/.tmp
$ svn log -v -r80 svn://devel.//branches/working

r80 | gpspbu | 2011-06-23 16:23:46 +0200 (Thu, 23 Jun 2011) | 1 line
Changed paths:
   M /trunk/030-Quellcode/[snip]
   A /trunk/030-Quellcode/[snip]
[snip other source code files]

Added WP31


[11:41:08] jg@ggajg ~/.tmp
$ svn log -v -r81 svn://devel.//branches/working

r81 | gpspbu | 2011-06-23 17:48:03 +0200 (Thu, 23 Jun 2011) | 1 line
Changed paths:
   A /branches/working (from /trunk:80)

Created a branch working of //trunk.


[11:41:21] jg@ggajg ~/.tmp
$ svn log -v -r82 svn://devel.//branches/working

r82 | ggapbu | 2011-06-23 17:58:49 +0200 (Thu, 23 Jun 2011) | 1 line
Changed paths:
   A /branches/working/030-Quellcode/GPSAssemblies/test.txt

test

Re: svnsync: Error while replaying commit

[Gary]

- Original Message -
From: Giulio Troccoli
On 02/04/12 11:10, Gary wrote:
> - Original Message -
> From: Giulio Troccoli
>> On 02/04/12 10:24, Gary wrote:
>>>> that still doesn't explain to me why svnsync barfs on those (not)
>>>> missing revisions. Looking at the command line history, I can't see
>>>> anywhere where I pointed svnsync at just the trunk, only ever at the
>>>> repo/project within the repo (I took my instructions from
>>>> http://svn.apache.org/repos/asf/subversion/trunk/notes/svnsync.txt)
>>>
>>> Well, at least we know that the revisions are not missing.
>>>
>>> Can you show us the source repository path for you synced repo? It
>>> should be in one of the properties stored in revision 0 in the synced
>>> repo, if I remember well.
>> Do you mean in the properties of the one I am trying to sync into, or
>> from?I'm not really sure what you mean :P
>
>Sorry, I wasn't very clear. The one your syncing into, so the 
>destination repo.

No problem. I don't know if this is exactly what you want, but:
$ cat ./db/revprops/0/0
K 8
svn:date
V 27
2011-03-01T16:14:38.678110Z
K 17
svn:sync-from-url
V 33
svn://devel./
K 18
svn:sync-from-uuid
V 36
7c76b8fe-c8ee-45e6-8ede-b17e10a7e991
K 24
svn:sync-last-merged-rev
V 1
0
END

So you mean the "sync-from-url" property? That looks correct, to me (with
my admittedly limited knowledge)

>>> Also, can you run svn log -v on revision 80, 81 and 82?
>> [11:41:02] jg@ggajg ~/.tmp
>> $ svn log -v -r80 svn://devel.//branches/working
>> 
>> r80 | gpspbu | 2011-06-23 16:23:46 +0200 (Thu, 23 Jun 2011) | 1 line
>> Changed paths:
>>     M /trunk/030-Quellcode/[snip]
>>     A /trunk/030-Quellcode/[snip]
>> [snip other source code files]
>>
>> Added WP31
>> 
>
>Why is it showing files in trunk when you're log command is for 
>branches/working ? Or have you just pasted the wrong command?

Nope, that's the command. I mean, it *is* the log, so... shouldn't it?
The commands for trunk and branch produce the same output, anyway:
[12:39:07] jg@ggajg ~/.tmp
$ svn log -v -r80 svn://devel.//trunk > trunk ; svn log -v -r80 
svn://devel.//branches/working > branch

[12:39:26] jg@ggajg ~/.tmp
$ diff -q trunk branch

[12:39:29] jg@ggajg ~/.tmp


> 

Re: svnsync: Error while replaying commit

[Gary]

- Original Message -
From: Giulio Troccoli
On 02/04/12 11:51, Gary wrote:
> - Original Message -
> From: Giulio Troccoli
> On 02/04/12 11:10, Gary wrote:
>> - Original Message -
>> From: Giulio Troccoli
>>> On 02/04/12 10:24, Gary wrote:
>>>>> that still doesn't explain to me why svnsync barfs on those (not)
>>>>> missing revisions. Looking at the command line history, I can't see
>>>>> anywhere where I pointed svnsync at just the trunk, only ever at the
>>>>> repo/project within the repo (I took my instructions from
>>>>> http://svn.apache.org/repos/asf/subversion/trunk/notes/svnsync.txt)
>>>> Well, at least we know that the revisions are not missing.
>>>> 
>>>> Can you show us the source repository path for you synced repo? It
>>>> should be in one of the properties stored in revision 0 in the synced
>>>> repo, if I remember well.
>>> Do you mean in the properties of the one I am trying to sync into, or
>>> from?I'm not really sure what you mean :P
>> Sorry, I wasn't very clear. The one your syncing into, so the
>> destination repo.
>> No problem. I don't know if this is exactly what you want, but:
>> $ cat ./db/revprops/0/0
>> K 8
>> svn:date
>> V 27
>> 2011-03-01T16:14:38.678110Z
>> K 17
>> svn:sync-from-url
>> V 33
>> svn://devel./
>> K 18
>> svn:sync-from-uuid
>> V 36
>> 7c76b8fe-c8ee-45e6-8ede-b17e10a7e991
>> K 24
>> svn:sync-last-merged-rev
>> V 1
>> 0
>> END
>> 
>> So you mean the "sync-from-url" property? That looks correct, to me (with
>> my admittedly limited knowledge)
>
>Well, I would have used svn pl -r0  to get the list of props (I didn't 
>remember its name) and then svn pg svn:sync-from-url -r0  but I guess 
>it's the same thing.
>
>It looks like you're syncing the whole repo. I was just checking :-)

Okay :)

>Howeve, why is svn:sync-last-merged-rev 0? It should be, well, the last merged 
>revision, 79 I think. I guess svn pg svn:sync-last-merged-rev shows 0 as well?

Oh, simply because I removed that (destination) repo once it was clear
it was not correct. I then recreated it this morning in order to perform
one or other operation you or someone else asked me to do.

If I do it now (having tried to sync again), I get:
$ cat db/revprops/0/0
K 8
svn:date
V 27
2011-03-01T16:14:38.678110Z
K 26
svn:sync-currently-copying
V 2
81
K 17
svn:sync-from-url
V 33
svn://devel./
K 18
svn:sync-from-uuid
V 36
7c76b8fe-c8ee-45e6-8ede-b17e10a7e991
K 24
svn:sync-last-merged-rev
V 2
80
END
as you expected.

>>> Why is it showing files in trunk when you're log command is for
>>> branches/working ? Or have you just pasted the wrong command?
>> Nope, that's the command. I mean, it *is* the log, so... shouldn't it?
>> The commands for trunk and branch produce the same output, anyway:
>> [12:39:07] jg@ggajg ~/.tmp
>> $ svn log -v -r80 svn://devel.//trunk>  trunk ; svn log -v 
>> -r80 svn://devel.//branches/working>  branch
>> 
>> [12:39:26] jg@ggajg ~/.tmp
>> $ diff -q trunk branch
>> 
>> [12:39:29] jg@ggajg ~/.tmp
>> 
>
>What version of SVN are you using? I've got 1.6.12 and if I am in a directory 
>where no changes were made for a revision then svn log doesn't show anything, 
>>e.g.
>
>svn log -v -r17727
>

$ svn --version
svn, version 1.6.17 (r1128011)
   compiled Jun  2 2011, 10:39:28

I'm not 100% sure what the server version is.

>In the list of files changed in revision 80 that you posted earlier, are there 
>any files at all that are actually in branches/working?
No, all are in trunk.

Re: svnsync: Error while replaying commit

[Gary]

- Original Message -

From: Giulio Troccoli

> Why is it showing files in trunk when you're log command is for
> branches/working ? Or have you just pasted the wrong command?
 Nope, that's the command. I mean, it *is* the log, so... shouldn't it?
 The commands for trunk and branch produce the same output, anyway:
 [12:39:07] jg@ggajg ~/.tmp
 $ svn log -v -r80 svn://devel.//trunk>   trunk ; svn log -v 
 -r80 svn://devel.//branches/working>   branch

 [12:39:26] jg@ggajg ~/.tmp
 $ diff -q trunk branch

 [12:39:29] jg@ggajg ~/.tmp

>>> What version of SVN are you using? I've got 1.6.12 and if I am in a 
>>> directory where no changes were made for a revision then svn log doesn't 
>>> show anything,>e.g.
>>>
>>> svn log -v -r17727
>>> 
>> $ svn --version
>> svn, version 1.6.17 (r1128011)
>>     compiled Jun  2 2011, 10:39:28
>>
>> I'm not 100% sure what the server version is.
>>
>>> In the list of files changed in revision 80 that you posted earlier, are 
>>> there any files at all that are actually in branches/working?
>> No, all are in trunk.
>
>That is really baffling me. But mayber that's because you have different 
>version.

Maybe. Don't know.

>I just thought something else. svnsync stops when trying to create the 
>branch (rev 81). So maybe the error is something not related to the 
>repository, like permission (I don't think so though) or some hooks. 
>Sorry, I am a bit to a dead end here.

Not to worry. I appreciate you trying to help. Thank you.

Repo moved - how to update working copies

[Gary]

The repo that I got my working copies from has moved, so I need to update them 
somehow. What is involved, please?

Re: Repo moved - how to update working copies

[Gary]

Many thanks. I'll give that a go. I just hope the new server isn't 1.7, because 
I know the old one was 1.6.


- Original Message -
From: Stefan Sperling 

On Wed, Apr 25, 2012 at 09:23:31AM +0100, Gary wrote:
> The repo that I got my working copies from has moved, so I need to update 
> them somehow. What is involved, please?
> 

1.6.x and earlier: svn help switch; see the --relocate option
1.7.x: svn help relocate

"svn cl" input from "svn st"

[Gary]

I'm just wondernig if it's possible to pipe or otherwise use the output from 
"svn st" into the "svn cl XYZ" command (for the file paths / names, obviously). 
I can't even see any option to "svn st" that gives *only* file names/paths :( 
The -q option seems to give the same output as "svn st" without it.

Re: "svn cl" input from "svn st"

[Gary]

> From: Stefan Sperling
> 
> On Thu, Apr 26, 2012 at 09:02:17AM +0100, Gary wrote:
> > I'm just wondernig if it's possible to pipe or otherwise use the output 
> > from "svn st" into the "svn cl XYZ" command (for the file paths / names, 
> > obviously). I can't even see any
> >  option to "svn st" that gives *only* file names/paths :( The -q option 
> > seems to give the same output as "svn st" without it.
> > 
> 
> Which operating system are you using?

Let's assume it's something *n*x like :)

Re: "svn cl" input from "svn st"

[Gary]

- Original Message -

From: Stefan Sperling 
...
> You can put these commands into a shell script to automate the task.
>
> Of course, it would be nicer if 'svn' had its own way of adding a
> select subset of files in the working copy to a changelist based on
> some criteria. But no such feature currently exists as far as I know.

Yeah, that's what I was wondering.

Thanks for the suggestion regarding sed or some such similar tool though!

Using subversion (or something else?)

[Gary .]

I am trying to decide, or at least get information to help me
decide, whether subversion or "something else" would be suitable
for us. Let me explain the situation. We use a product which we
customise and add features to, both of which mean changing the
source. Sometimes these changes also get accepted by the vendor
and are included in the next release. So when we get a new
release we get a new bundle of source files and so forth (in some
format which I don't know offhand, but probably isn't important
to this anyway), and we then have to manually merge the changes
we have made to the last version into the new version, some of
which might be changes we already have.

I think one way of thinking about it is that our changes are a
series of patches, some of which are accepted upstream and some
not (this is what makes me wonder whether something other than
subversion might be better for us, but that might be just my
brain making a connection between the word "patch" and systems
that I know use this kind of patching concept, such as
darcs). Maybe there is an alternative way of thinking about the
situation which means that subversion, which I am more at home
with, would be suited.

So the first question is, do you think subversion is suitable in
this case, and if not is there something "better" (in the sense
it will be easier for us to use) that you can recommend?

So the first question is, do you think subversion is suitable in
this case, and if not is there something "better" (in the sense
it will be easier for us to use) that you can recommend?

Secondly, if subversion is suitable, what's the best way to use
it in this situation (regarding branching, releasing, etc.)? I
worked somewhere with this kind of situation before (changing and
customising vendor code, with new vendor releases being
introduced from time to time), and we basically used branches for
each new vendor, and internal, release. Where I am now, we have a
very short internal release cycle, along the lines of "code it,
ship it!" (we effectively work directly on the live system, which
I am not in favour of, but we do need that quick turnaround from
code-change to production system). At the other place we had a
script that did a lot of the merging between the production
branch, where bug fixes would be implemented, and the "new
features" branch where we would be working. Obviously I don't
have that script now, but is there anything around that can do
that kind of merging, if I managed to convince people to adopt
that kind of way or working? Or is there some better way of
working in this situation? Okay, so "better" is somewhat
subjective, but I am open to ideas so don't be afraid to throw
them into the middle.

Thanks in advance for your suggestions.

Re: Using subversion (or something else?)

[Gary .]

On Fri, May 21, 2010 at 11:58 AM, Ryan Schmidt wrote:
> On May 21, 2010, at 04:32, Gary . wrote:
>
>> We use a product which we
>> customise and add features to, both of which mean changing the
>> source. Sometimes these changes also get accepted by the vendor
>> and are included in the next release.
>
> The Vendor Branches chapter in the book addresses how you can handle this in 
> Subversion.

Oh! How embarrassing. I'm just reading that document as it happens,
but hadn't got that far through it yet :) Thanks for the hint!

Re: Using subversion (or something else?)

[Gary .]

On Fri, May 21, 2010 at 11:58 AM, Ryan Schmidt wrote:
> The Vendor Branches chapter in the book addresses how you can handle this in 
> Subversion.
>
> http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html

Hrmph. I couldn't get the example in the doc to work whentrying
it with a toy example:

j...@work ~/work/svntest
$ svn import ./foobar file:///mnt/h/svn/GDJ/foobar -m "initial drop"
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///mnt/h/svn/GDJ/foobar'

where:
j...@work ~/work/svntest
$ ls -la /mnt/h/svn
total 0
drwxr-xr-x+ 1 jg  Domänen-Benutzer 0 May 21 14:46 .
drwx--+ 1 Administratoren Domänen-Benutzer 0 May 21 14:40 ..
drwxr-xr-x+ 1 jg  Domänen-Benutzer 0 May 21 12:56 jg

Accessing the jg project is fine:
j...@work ~/work/svntest
$ svn list file:///mnt/h/svn/jg
.bashrc
.bashrc.d/
.emacs.d/
.emacs.el
.gnus/
.gnus.el

Of course, GDJ doesn't exist. Am I supposed to create this first?
Apparently so, although the documentation doesn't mention this:
j...@work ~/work/svntest
$ svnadmin create /mnt/h/svn/GDJ

j...@work ~/work/svntest
$ svn import /home/jg/work/svntest/foobar file:///mnt/h/svn/GDJ/foobar
-m "initial drop"
Adding  ...(many files)
...
Committed revision 1.

But I still get a very similar error when I try to to tag the
stuff. The tagging of the "vendor data" went okay, but, after
creating my project structure:
$ svn import . file:///mnt/h/svn/myproject -m "create project structure"
Adding trunk
Adding branches
Adding tags

Committed revision 1.

when trying to copy the "vendor data":
j...@work ~/work/svntest
$ svn copy file:///mnt/h/svn/GDJ/foobar/0.1 \
file:///mnt/h/svn/myproject/trunk/foobar \
-m "bring foobar-0.1 into driver project"
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///mnt/h/svn'

Huh? "Unable to open repository 'file:///mnt/h/svn'"? To which
URL is it even referring?

Re: Using subversion (or something else?)

[Gary]

Les Mikesell wrote:
> On 5/21/2010 8:52 AM, Gary . wrote:
>> Accessing the jg project is fine:
>> j...@work ~/work/svntest
>> $ svn list file:///mnt/h/svn/jg
>> .bashrc
[...]

> Which has nothing to do with the location you tried to use in the
> failing import.

No. I just wanted to show that the basic paths existed (/mnt/h/svn)
because of the "Unable to open repository" message below.

>> when trying to copy the "vendor data":
>> j...@work ~/work/svntest
>> $ svn copy file:///mnt/h/svn/GDJ/foobar/0.1 \
>> file:///mnt/h/svn/myproject/trunk/foobar \
>> -m "bring foobar-0.1 into driver project"
>> svn: Unable to open an ra_local session to URL
>> svn: Unable to open repository 'file:///mnt/h/svn'
>>
>> Huh? "Unable to open repository 'file:///mnt/h/svn'"? To which
>> URL is it even referring?
>
> You can only svn copy with url's pointing to within the same
> repository. Or you can do it locally in a checked out working copy and
> commit it back.

Ah okay. Thanks. Will try again next week when I am back at
work. Perhaps the redbook is misleading here then, because going purely
by the text in the commands shown in the example it looks like two
different repositories are involved:
,
| $ svn copy http://svn.example.com/repos/vendor/libcomplex/1.0  \

|http://svn.example.com/repos/calc/libcomplex\
^^
|-m "bringing libcomplex-1.0 into the main branch"
`

>  And is that file:///mnt/h/svn/GDJ/foobar/0.1 supposed
> to refer to a revision or is that a subdirectory you imported there?

I did my local equivalent of
,
| $ svn copy http://svn.example.com/repos/vendor/libcomplex/current  \
|http://svn.example.com/repos/vendor/libcomplex/1.0  \
|-m "tagging libcomplex-1.0"
`
before that ('The tagging of the "vendor data" went okay' in my last
post).

-- 
Gary

Re: Using subversion (or something else?)

[Gary]

Ryan Schmidt wrote:
> On May 22, 2010, at 06:24, Gary wrote:
>> ,
>> | $ svn copy http://svn.example.com/repos/vendor/libcomplex/1.0  \
>>
>> |http://svn.example.com/repos/calc/libcomplex\
>>^^
>> |-m "bringing libcomplex-1.0 into the main branch"
>> `
>
> The Subversion project generally uses term "repos" to abbreviate the
> word "repository", *not* the word "repositories"

Oh my good grief.

Thanks, Ryan!

-- 
Gary

missing key from subversion-1.14.4.KEYS?

[Gary Martin]

Hi,

Is there a missing public key in the subversion-1.14.4.KEYS file currently
available via https://subversion.apache.org/download.cgi - trying to verify
the artifacts seems to be failing...

  > gpg --verify subversion-1.14.4.tar.gz.asc subversion-1.14.4.tar.gz
  [ ... ]
  gpg: Can't check signature: No public key

... until I was able to find a key for rinrab and import that too.

Cheers,
Gary

-- 





THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY 
BE PRIVILEGED


If this message was misdirected, Cirata Ltd. and its 
subsidiaries, ("Cirata") does not waive any confidentiality or privilege. 
If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone. Any 
distribution, use or copying of this email or the information it contains 
by other than an intended recipient is unauthorized. The views and opinions 
expressed in this email message are the author's own and may not reflect 
the views and opinions of Cirata, unless the author is authorized by Cirata 
to express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by Cirata. 
Although Cirata operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

Lost changes

[Gary Weinfurther]

I have a team of about seven people, both on Macs and PCs.  Within the last 
couple of weeks, we have been experiencing frequent occurrences of lost 
changes.  Someone will commit a change and later we discover that the change 
has been reverted.  Everyone claims that they are updating before they work on 
files.  Even if this was not always true, the SVN clients should catch commits 
that were not on the most recent files, correct?

Server is VisualSVN 2.5.3.

PC Clients:

TortoiseSVN 1.7.5, Build 22551 - 64 Bit

Mc Clients:

SmartSVN 6.6.11

SmartSVN Early Access 7EA4

Subversion Client Adapter for Eclipse 1.6.12
Subversion JavaHL 1.6.17
SVN Team Provider Core 1.6.18

Versions 1.1.10 Build 1029


I am not subscribed. Please CC me on replies.

Gary

can I use svn:externals instead of svn copy to create a tag?

[Gary Hallmark]

All examples I have seen for tagging use svn copy (or svncopy -tag) to 
create a tag. If I want to make sure nobody can change the tag, I guess 
I could write a commit hook. But couldn't I use a versioned external 
definition to create the tag instead of svn copy? Seems this would 
better enforce that nobody can change the tag, since it isn't a copy at 
all. One downside would be that if the tag contains unversioned 
externals, I would not be able to pin them down, but I don't plan to 
have unversioned externals. Are there any other downsides?


Example:
trunk/
tags/
   X -r123 ^trunk version_1.0

Cheers,
 Gary

This application has halted due to an unexpected error.

[Gary Gregory]

Hi All:

Crash report attached.

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory


svn-crash-log20130812144701.log
Description: Binary data

svn merge issues after upgrading server from 1.4.3 to 1.6.6 - unexpected property changes (deleted svn:mergeinfo)

[Gary M. Gere]

-All,

This is my first time posting to this alias; I apologize in advance for 
any protocol mistakes, but we are in a serious situation and I need to 
get some guidance/help as soon as possible.


I tried searching through the issues database but could not find 
anything that appeared to be the issue we are encountering, so I am 
posting this request.


We recently upgraded our subversion server software and are having major 
problems with merging after moving the subversion server from 1.4.2 to 
1.6.6. I am asking the user community for any help they can give us.


The details of the prior and current software versions are detailed at 
the end of this email.


The problem we are having is with 'svn merge' with a workspace that was 
checked out using the subversion 1.4.2 server:


  - cd 
  - svn merge -r revision1:revision2 SOURCE_SVN_URL .

This results in many unrelated files are having their properties change, 
and many unrelated files being included in the merge. It makes it very 
difficult to verify that the merge was successful when many unrelated 
files are included.


A small example:

An attempt to merge one change from sw1.0 to sw2.0 branch.
A folder called Docs contains files that have not been changed.
An svn diff produces the following:

   % cd /data/source/branches/sw2.0
   % svn stat -q Docs/
 M  Docs/WDS-RIS-Blueprint.odt
 M  Docs/WDS-RIS-Script-Usage.odt

   % svn diff Docs/

   Property changes on: Docs/WDS-RIS-Blueprint.odt
   ___
   Deleted: svn:mergeinfo


   Property changes on: Docs/WDS-RIS-Script-Usage.odt
   ___
   Deleted: svn:mergeinfo

A mix of subversion clients have been in use, including 1.4, 1.5 and 1.6 
based clients. Those have not changed, and this behavior occurs even 
using a 1.6.9 client.


Can anyone provide any guidance, clues, pointers, etc. to what we need 
to do to address this issue??


Thank you very much in advance,
-GmG

Prior to last Monday 22-Mar-2010, we had a system running the following:
  - RHEL-5.3 64-bit (Linux 2.6.18-128.1.6.el5 #1 SMP Tue Mar 24 
12:05:57 EDT 2009 x86_64)
  - subversion 1.4.2 (r22196, Sep 1 2008) (subversion-1.4.2-4.el5, 
subversion-devel-1.4.2-4.el5, subversion-javahl-1.4.2-4.el5, 
subversion-perl-1.4.2-4.el5, subversion-ruby-1.4.2-4.el5)
  - openssl OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 
(mod_ssl-2.2.3-22.el5, openssl097a-0.9.7a-9.el5_2.1, 
openssl-0.9.8e-7.el5, openssl-devel-0.9.8e-7.el5)
  - httpd Apache/2.2.3 (Nov 12 2008) (httpd-2.2.3-22.el5, 
httpd-devel-2.2.3-22.el5, system-config-httpd-1.3.3.3-1.el5)

  - Berkeley DB 4.3.29 (db4-4.3.29-9.fc6, db4-devel-4.3.29-9.fc6)

The subversion repository is format "3"

We upgraded the system to:
  - RHEL-5.4 64-bit (Linux 2.6.18-164.el5 #1 SMP Thu Sep 3 04:15:13 EDT 
2009 x86_64)
  - subversion 1.6.6 (r40053, Oct 22 2009) 
(subversion-1.6.6-0.1.el5.rf, subversion-devel-1.6.6-0.1.el5.rf, 
subversion-perl-1.6.6-0.1.el5.rf)
  - openssl OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 
(Mod_ssl-2.2.3-31.0.1.el5, openssl-0.9.8e-12.el5_4.1, 
openssl-devel-0.9.8e-12.el5_4.1, openssl-perl-0.9.8e-12.el5_4.1)
  - httpd Apache/2.2.3 (Sep 3 2009) (httpd-2.2.3-31.0.1.el5, 
httpd-manual-2.2.3-31.0.1.el5, system-config-httpd-1.3.3.1-1.el5.0.1)

  - Berkeley DB 4.3.29 (db4-4.3.29-10.el5, db4-devel-4.3.29-10.el5)

The subversion repository was not upgraded and is still in format "3".

Re: svn merge issues after upgrading server from 1.4.3 to 1.6.6 - unexpected property changes (deleted svn:mergeinfo)

[Gary M. Gere]

-Hi Bob,

First off, thank you very much for your quick reply.

We were running a 1.4.2 subversion server, and upgraded the subversion 
server to 1.6.6. The clients have not changed in any way, and were a mix 
of 1.4, 1.5 and 1.6 clients that used "http" only to communicate with 
the subversion server. We have not had any compatibility issues of any 
kind until we upgraded the server to 1.6.6.


The merge problem did not show up when the server was 1.4.2, but is now 
showing up with the 1.6.6 server.


We did not upgrade the database repository - it is still at version "3". 
I read somewhere in the 1.5 release notes that the "merge tracking" 
added to 1.5 will not be enabled unless the repository is upgraded, 
which it has not.


If I understand your reply correctly, what's happening is old 
svn:mergeinfo data that is no longer needed is being removed (property 
change only). Even though a large number of files are listed in the 
merge/commit, besides files that really were merged, the rest are just 
property changes.


Thank you very much.

-GmG


On 03/25/10 12:04, Bob Archer wrote:

We recently upgraded our subversion server software and are having major
problems with merging after moving the subversion server from 1.4.2 to
1.6.6. I am asking the user community for any help they can give us.

The details of the prior and current software versions are detailed at the
end of this email.

The problem we are having is with 'svn merge' with a workspace that was
checked out using the subversion 1.4.2 server:
 

Eww... not sure how great an idea it is to use a pre 1.5 server with 1.5 and 
1.6 clients. Although I'm not 100% sure of the ramifications... it could just 
be a performance issue and the client has to do more work to walk the tree of 
mergeinfo properties. Perhaps someone that knows a bit more about that issue 
will chime in here.

   

   - cd
   - svn merge -r revision1:revision2 SOURCE_SVN_URL .

This results in many unrelated files are having their properties change,
and many unrelated files being included in the merge. It makes it very
difficult to verify that the merge was successful when many unrelated
files are included.

A small example:

An attempt to merge one change from sw1.0 to sw2.0 branch.
A folder called Docs contains files that have not been changed.
An svn diff produces the following:
% cd /data/source/branches/sw2.0
% svn stat -q Docs/
  M  Docs/WDS-RIS-Blueprint.odt
  M  Docs/WDS-RIS-Script-Usage.odt

 

As you know a " M" (Space in first col M in second column) indicates that the 
properties where changed but not the file itself.


   

% svn diff Docs/

Property changes on: Docs/WDS-RIS-Blueprint.odt
___
Deleted: svn:mergeinfo


Property changes on: Docs/WDS-RIS-Script-Usage.odt
___
Deleted: svn:mergeinfo
 

This shows that you do have mergeinfo on your files. So, at some time someone 
did a merge probably at the Docs level or directly to a file which added the 
mergeinfo. Now you are doing it at a higher folder level so the data is being 
elided. There's not really anything wrong here.

You  might want to train your devs to always do merges at the same folder level 
to prevent all the merge data on child folders and files. If they weren't there 
then they wouldn't be elided.


   

A mix of subversion clients have been in use, including 1.4, 1.5 and 1.6
based clients. Those have not changed, and this behavior occurs even using
a 1.6.9 client.
 

I assume it doesn't happen when you use a 1.4 client... since this version 
doesn't include the merge tracking functionality.


   

Can anyone provide any guidance, clues, pointers, etc. to what we need to
do to address this issue??
 

I think there is nothing you can do to address it. But, to solve your problem you may 
just want to pipe the output to grep (or something) and ignore files with a status of 
" M"

You might also want to upgrade your server... 1.4.x is pretty old and not 
supported with updates.

I hope this helps.. sorry AFAIK there is no magic answer to make this easier.

BOb