Re: svnsync error : Error while replaying commit

[Stefan Hett]

Hi,

you might wanna repost your question in English. I'm not sure whether 
anybody here can read Chinese (if it is Chinese, that is).
All I can make out of this report is that you seem to get some error 
running svnsync which seems to be a rather old version (1.7.4). If you 
want/need to stick with 1.7, I suggest you at least upgrade to the 
latest 1.7-version (which is 1.7.22 at the time of writing this) or even 
a later (and still supported) version like 1.8/1.9.



我也遇到了该问题Error while replaying
commit，有些库用下面同样的步骤操作是没问题的，但是有些库就报这个错，不知道为什么，麻烦大家遇到过解决了的回答下，谢谢
我的操作步骤是
1、将脚本aapost-commit.bat放置到SVN主服务器相对应项目的hooks文件里，
例如：\\192.168.27.1\d$\SVN\c3m-video\hooks
"C:\Program Files (x86)\Subversion\bin\svnsync.exe" sync --non-interactive
svn://192.168.27.88/c3m-video --username admin --password cmadmin
修改下面一行中的备份服务器IP和项目名
2、将脚本Svn Start Server.bat放置在备份服务器SVN文件的同目录下
svnserve -d -r e:\SVN 修改对应的存储盘符
3、将脚本pre-revprop-change.bat放置在备份服务器相应项目的hooks文件夹下。例如：
\\192.168.27.1\d$\SVN\c3m-video\hooks
二、操作命令  (在备份服务器上操作)
1、连接 svnsync init svn://192.168.27.88/C3M-EMS svn://192.168.27.1/C3M-EMS
2、同步 svnsync sync svn://192.168.27.88/MVSS --username admin --password
cmadmin

主服务是Windows sever 2008 R2，备份服务器是Windows sever 2008 R2
SVN服务版本为Setup-Subversion-1.7.4



--
View this message in context: 
http://subversion.1072662.n5.nabble.com/svnsync-error-Error-while-replaying-commit-tp156531p196592.html
Sent from the Subversion Users mailing list archive at Nabble.com.




--
Regards,
Stefan Hett

Re: Migrate svn, version 1.6.11 (r934486) to svn verion 1.9.3

[Stefan Hett]

Hi Brandon,

you can load older dumps into newer versions. So there should be no 
reason to upgrade prior to the migration.


The only thing I'd consider is to upgrade the server to 1.6.23, since 
1.6.11 is rather outdated on the 1.6 branch and therefore there might be 
bugs in the dump logic which would have been fixed in a later 1.6 build 
(I'm not particularly aware of any specific issue here --- just 
suggesting a general I normally follow myself).


Obviously if there is no easy way to upgrade SVN to 1.6.23 on CentOS 
5.8, I'd also skip that. Worst case, you will still have the original 
repository backed-up so you can always replay the migration procedure.



Is an upgrade needed prior to migrating a repo if going to another 
version of svn? I wonder if 1.9.3 is supported on CentOS 5.8



*From: *"Gronde, Christopher (Contractor)" 
*To: *"Brandon L. Wisenburg" 
*Sent: *Thursday, May 5, 2016 7:40:38 AM
*Subject: *RE: Migrate svn, version 1.6.11 (r934486) to svn verion 1.9.3

I am actually doing the same exact thing and this is the first time 
I’ve upgraded SVN. The installer I got from WanDISCO and It seems 
pretty self-explanatory. Our intention is to do an in-place upgrade 
and then focus on transferring from RHEL6 to RHEL7 later and probably 
move from authenticating from FreeIPA to Active Directory. If you have 
any tips on upgrading I’d appreciate that as well!





From: Brandon L. Wisenburg [mailto:bran...@wisenburg.com]
Sent: Wednesday, May 04, 2016 10:27 PM
To: users@subversion.apache.org
Subject: Migrate svn, version 1.6.11 (r934486) to svn verion 1.9.3





Hello All.


I am working on a project to migrate a repo to a new server that is 
more up-to-date and runs a newer OS and newer version of subversion. 
I've done this before, between similar versions of subversion. I was 
wondering, are there any got ya's that I should be aware of regarding 
migration a 1.6.11 svn to 1.9.3? Does it matter much the different 
versions? Does anyone have any insight and experience they'd like to 
share?






Many Thanks.



--
Regards,
Stefan Hett

Problem with locking multiple files.

[Stefan Hett]

Hi,

this is in reference to a user reported problem on the TSVN mailing list [1]

The user is having an issue with using TSVN 1.9.4 over a Java-SSL-Tunnel 
when trying to lock hundreds or thousands of files. The same operation 
works without problems when:

- using TSVN 1.8.12 or
- using the SVN command line client (1.8 or 1.9)
- disabling the Java-SSL-Tunnel

I've been pointed to issue #4557 [2] by stsp. I'm not 100% certain 
whether this really is the particular problem the user runs into but 
even if it wouldn't be the case here, the underlying issue of #4557 
might be worth changing/fixing in 1.9 as well.


The reasoning from a users / downstream-developer's point of view would 
be that the new way could fail in a particular environment which the old 
(aka: 1.8) way would work just fine. So if I as a developer make use of 
the new functionality, it would look like a regression to my userbase of 
my tool.


Does that make sense to you? Should I create a new JIRA issue for that 
case (in contrast to SVN-4557 that would differ in that the effected 
version would be 1.9.x - not 1.8.x - aka: no regression)?



[1] 
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171337

[2] https://issues.apache.org/jira/browse/SVN-4557

--
Regards,
Stefan Hett

show fortran subroutine/function names in diff chunk headers

[Keith Lindsay]

Hi,

I use svn and git in different projects. I've learned that if I place
*.f90 diff=fortran
in ~/.config/git/attributes, then git diff shows fortran
subroutine/function names
in the hunk headers. I'm trying to get similar functionality for svn diff.

I see that there is a svn option -x -p for C functions, but I haven't
figured out a
corresponding option for fortran.

I've tried setting diff-cmd=... and diff-extensions=... in ~/.subversion/config,
but I haven't figured out how to get the desired results. Also, it
seems like the
diff command line options with this approach would be applied to all diff
invocations, not just when diff is being applied to fortran files.

How I can get this functionality for svn diff?

I am not subscribed to the mailing-list, so please cc me on replies.

Thanks, Keith Lindsay

Subversion checkout behavior at non-existent revision

[Tati, Aslesh]

Hi,

I have a question about the behavior of svn checkout. Here is the scenario:
I have a standard trunk, branches, tags structure for one of my apps in a repo 
and I created a branch, say at revision 500 of trunk.
Later, I delete the branch and the recreate another branch with the same name 
and at the same revision 500 of trunk.

Now I'm trying to check out the branch at revision 500. I know that the branch 
doesn't exist at r500 (it will be some higher revision), only trunk does and it 
probably doesn't make sense to check out a branch at that revision; but I'm 
interested in knowing why this behavior occurs and if it is expected.

svn co /branches/@500 --> svn info on that gives the URL as 
expected i.e. /branches/

svn co -r 500 /branches/ --> svn info on that gives an 
unexpected result i.e. /trunk

Shouldn't subversion complain that the branch doesn't exist at revision 500?
If it has checked out without complaining, why does svn info using the second 
way of checkout show the unexpected result?

Thanks,
Aslesh Tati

Barclaycard

www.barclaycardus.com

This email and any files transmitted with it may contain confidential and/or 
proprietary information. It is intended solely for the use of the individual or 
entity who is the intended recipient. Unauthorized use of this information is 
prohibited. If you have received this in error, please contact the sender by 
replying to this message and delete this material from any system it may be on.

Re: Blank lines

[Ryan Schmidt]

On May 5, 2016, at 4:12 PM, webster.br...@rogers.com wrote:
> 
> From: Branko Čibej 
> 
>> Not 'status' -- 'svn status' should always show what 'svn commit' will
>> send to the server. But 'diff', I agree, could be smarter. For example,
>> right now, 'svn diff --summarize -x -w' will mention files that contain
>> only whitespace changes, even though 'svn diff -x -w' will show an empty
>> diff for those files.
> 
> You should wrapper the diff command
> 
> svn diff --diff-cmd 'diff -x -w'

Not quite.

--diff-cmd is for specifying the name of the diff program to run, e.g. diff. If 
you want to name a diff program whose path or name contains spaces, then you 
have to quote it, but that would be unusual.

svn diff --diff-cmd '/path with spaces/to/diff'

-x is for specifying the arguments to pass to that diff program, e.g. -w. If 
you want to pass multiple arguments to the diff program, you have to quote them.

svn diff --diff-cmd diff -x '-u -w'