Re: Historic merge "done wrong" doesn't work in up to date working copy
On Mon, Jan 23, 2017 at 11:29:03AM -0500, Kris Deugau wrote: > I've been maintaining a set of spam filter rule files in Subversion for some > time. On the client side this has been almost entirely with 1.6.x on CentOS > 5. > > I've just recently done a major refresh on my PC, switching to the current > Debian stable release, with Subversion 1.8.10. > > The directory structure I've suddenly found I've been merging incorrectly > looks like: > > dev/ > file1.cf > file2.cf > file3.cf > ... > prod/ > file1.cf > file3.cf > ... > > (Note a small number of files were added in dev/, but have not been copied > to prod/. IIRC the few files added to SVN in dev/ but not prod/ got added > by the merge, then revert'ed, then OS-rm'ed.) > > dev/ and prod/ were created at the same time, in r1. Files were created in > dev/, then svn cp'ed to prod/. > > With the old 1.6 client, I was able to "svn merge ^/dev" in prod/, and it > did what I expected; merge all changes to the relevant files (and add the > occasional new file) from dev/ to prod/. merginfo is only maintained on the > prod/ directory, not individual files. > > With 1.8, it's now complaining that dev/ and prod/ have no common ancestor. > > What can I do to get unstuck? > > -kgd You could use the --ignore-ancestry option but because this disables merge tracking you'll also either need to specify one or more revisions to merge, or use the 2-URL merge syntax. See 'svn help merge' for more details. For the long term, I would recommend to reconcile the branches, then delete one of the branches and recreate it as a copy of the other.
Historic merge "done wrong" doesn't work in up to date working copy
I've been maintaining a set of spam filter rule files in Subversion for some time. On the client side this has been almost entirely with 1.6.x on CentOS 5. I've just recently done a major refresh on my PC, switching to the current Debian stable release, with Subversion 1.8.10. The directory structure I've suddenly found I've been merging incorrectly looks like: dev/ file1.cf file2.cf file3.cf ... prod/ file1.cf file3.cf ... (Note a small number of files were added in dev/, but have not been copied to prod/. IIRC the few files added to SVN in dev/ but not prod/ got added by the merge, then revert'ed, then OS-rm'ed.) dev/ and prod/ were created at the same time, in r1. Files were created in dev/, then svn cp'ed to prod/. With the old 1.6 client, I was able to "svn merge ^/dev" in prod/, and it did what I expected; merge all changes to the relevant files (and add the occasional new file) from dev/ to prod/. merginfo is only maintained on the prod/ directory, not individual files. With 1.8, it's now complaining that dev/ and prod/ have no common ancestor. What can I do to get unstuck? -kgd
Re: SVN BUG
On Mon, Jan 23, 2017 at 6:20 AM, Swamy, Gagana Prabhu wrote: > Hi , > > > > Recently I faced the following issue: > > > > 1)My password that is used is “#anusuya2893#” > > 2)While checking out, I mistakenly used the password “#anusuya#” and it > worked fine without any error and the operation was successful also . That doesn't sound like a Subversion bug. That sounds like you are using an old version if underlying Apache software with a *horrible* password handling module. Please publish which operating system, which version of Subversion, and whether you are using web based access living on top of an old Apache release, or using "svnserve" directly, or using svn+ssh based access to the Subversion server. Each of those technologies can use different underlying authentication. Only one of them, svnserve, is built into Subversion itself on the server side. > 3)Any other combinations is not working but the 2 combinations(1 proper and > the other improper combination) are working which I feel is wrong > Please let me know if this is an issue . Sure sounds like an issue. I doubt it's a Subversion issue, for reasons mentioned above. > Thanks & Regards, > > Gagana > > Sonus Networks > > Bangalore > >
Re: SVN BUG
> On Jan 23, 2017, at 05:20, Swamy, Gagana Prabhu wrote: > > Hi , > > Recently I faced the following issue: > > 1)My password that is used is “#anusuya2893#” > 2)While checking out, I mistakenly used the password “#anusuya#” and it > worked fine without any error and the operation was successful also . > 3)Any other combinations is not working but the 2 combinations(1 proper and > the other improper combination) are working which I feel is wrong > > Please let me know if this is an issue . > What version of Subversion on the client and server? What OS on the client and server? What server is being used? svnserve? mod_dav_svn? What password authentication method is being used on the server?
SVN BUG
Hi , Recently I faced the following issue: 1)My password that is used is "#anusuya2893#" 2)While checking out, I mistakenly used the password "#anusuya#" and it worked fine without any error and the operation was successful also . 3)Any other combinations is not working but the 2 combinations(1 proper and the other improper combination) are working which I feel is wrong Please let me know if this is an issue . Thanks & Regards, Gagana Sonus Networks Bangalore
Re: merginfo corruption?
Hi, I have been sidetracked by other work for a while, but would like to get back to this now... I double-checked this and checked out the branch at r8689. This is the result % svn co svn://svn.nublado.org/cloudy/branches/backtrace@8689 % cd backtrace/ % svn proplist --verbose source/ [...snip...] /trunk/source:8667-8688 So the revision in question is definitely marked as merged there... This looks OK, which is also consistent with the fact that subsequent merges from trunk showed no problems (r8784, r8788, r8815, r11144). You're only looking at one path. Mergeinfo is only inherited to paths which do not have an svn:mergeinfo property themselves. In my example above, svn:mergeinfo on the root of the working copy is irrelevant for any child (directory or file) within subtree A. Only mergeinfo on subtree A is considered for those children (unless of course where children have svn:mergeinfo themselves). The backtrace branch has only been maintained by me, and my routine has always been to merge all changes from the root of the trunk to the root of the branch and then commit from the root of the branch. So I would expect the mergeinfo to be the same on subdirectories or individual files. However, when I checked this, I found this not to be the case. These paths have separate mergeinfo records at r8689: data/lamda/masterlist/Lamda.ini source tsuite/auto/chianti_all_cool.dat tsuite/auto/chianti_all_cool.in Apart from "source" they are all files. The full mergeinfo record for source is svn:mergeinfo /branches/HfsLines/source:6561-8024 /branches/SED/source:6190-7044 /branches/WangYe/source:5202-5690 /branches/block/source:6454-6465 /branches/cden/source:6478-6586 /branches/chianti/source:5345-5686,6680-6806 /branches/collapsed/source:7331-8615 /branches/convergence/source:8443-8533,8561-8633 /branches/convfix/source:7216-7234 /branches/depart/source:7256-7655 /branches/diatoms/source:4635-5051 /branches/fixct/source:5862-5945 /branches/gtest/source:7057-7198 /branches/h2star/source:5156 /branches/ionrec/source:4983-5281 /branches/linesInit/source:6627-6633 /branches/newmole/source:502-6043 /branches/nstout/source:8422-8435 /branches/optnl/source:6638-6757 /branches/ots2/source:6379,6393-6394,6429-6430,6448 /branches/parser/source:3753,3755,3763 /branches/parser2/source:7036-7070 /branches/romas3/source:6262-6786 /branches/stout/source:6885-6945,6976-7373,7388-7415,7417-7420,7668-7671,8202-8203,8378-8395 /branches/stout1/source:8135-8171 /branches/stout2/source:6109-6538,7581-7619,7694-7706 /branches/stout3/source:7626-7633,7635-7663 /branches/sup/source:7503-7533 /trunk/source:8667-8688 So it has the same information for /trunk as the record at the root. The three files with individual mergeinfo records look different. One example for tsuite/auto/chianti_all_cool.dat is svn:mergeinfo /branches/FixWvlng/tsuite/auto/chianti_all_cool.dat:7890-7912 /branches/collapsed/tsuite/auto/chianti_all_cool.dat:8609-8615 /branches/convergence/tsuite/auto/chianti_all_cool.dat:8443-8533,8561-8633 /branches/nstout/tsuite/auto/chianti_all_cool.dat:8422-8435 /branches/stout/tsuite/auto/chianti_all_cool.dat:8202-8203,8378-8395 So at revision 8689, the mergeinfo records at the root and the source subdirectory both indicate that r8669 is already merged at that point. Yet, when I do the merge now (at the head of this branch), it wants to merge changes in source/rt_continuum_shield_fcn.cpp from r8669. For me this points to corruption in the mergeinfo record or a bug in subversion (or both of course...). So I would like to consider the svn-mergeinfo-normalizer tool that was mentioned earlier in this thread. But I need additional guidance on how to compile it and how I should use it. Do I need to fix the trunk, or the development branch, or both? How does this compare to the mergeinfo-sanitizer.py script? Cheers, Peter.
