Re: Error while updating
Guten Tag Ajay Pawar, am Mittwoch, 24. April 2013 um 07:03 schrieben Sie: Please help ASAP as the SVN user are not able to any work. You changed something and now get errors, therefore you are the only one who can resolve your issues, we can only provide some hints. Some of those are to check permissions, availibility of the storage underneath the repos, checking the repos with error using svnadmin verify, using Prosess Monitor to filesystem access during accessing the problematic repos by the clients etc. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
RE: Error while updating
Hi Thorsten, Thanks for your reply. SVN Admin verify is showing an error called Can't read end of file. Regards, Ajay Pawar -Original Message- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: Wednesday, April 24, 2013 12:11 PM To: users@subversion.apache.org Subject: Re: Error while updating Guten Tag Ajay Pawar, am Mittwoch, 24. April 2013 um 07:03 schrieben Sie: Please help ASAP as the SVN user are not able to any work. You changed something and now get errors, therefore you are the only one who can resolve your issues, we can only provide some hints. Some of those are to check permissions, availibility of the storage underneath the repos, checking the repos with error using svnadmin verify, using Prosess Monitor to filesystem access during accessing the problematic repos by the clients etc. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Error while updating
On 4/23/2013 11:43 PM, Ajay Pawar wrote: Hi Thorsten, Thanks for your reply. SVN Admin verify is showing an error called Can't read end of file. This means your repository was corrupted somehow. svnadmin verify checks the integrity of the repository where all of your data is stored. Thus it is a first step in diagnosing unusual error messages. Perhaps there was a hardware failure on the machine or the disk drive. It is also possible that the Visual SVN installation had a problem, because error reports began soon afterward. If only a small number of revisions within the repository were damaged, then it is possible that only a subset of the Subversion file system would fail to work. Thus not everyone would get error messages. You should paste the entire svnadmin verify error message (after removing anything site-specific, like host names, from the URLs) so people can help you identify the location of the error and suggest fixes. You are providing only partial information. In particular, summarizing the error message is not as useful as pasting all of it. A fix may be as simple as restoring individual revision files from a backup (you do have backups of the repository, right?), but the Subversion users list needs to know more about the problems you are having. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Hard-to-understand error message after merge
Hi,
One of my colleagues got a hard-to-decipher error message after
trying to do a merge (trunk - branch):
svn: E27: Can't add '{some-path}\svntest\C\B' with URL
'{repo-path}/svn-test/A/B', but with the data from
'{repo-path}/tools/trunk/makecd'
svn: E175002: Error reading spooled REPORT request response
After about an hour of head scratching we figured out that something
like the following had occurred:
svn mkdir -m Creating test structure {repo-path}/svn-test
Committed revision 971.
svn co {repo-path}/svn-test .
Checked out revision 971.
svn mkdir A
A A
svn ci -m Created A
Adding A
Committed revision 972.
cd A
svn propset svn:externals B {repo-path}/tools/trunk/makecd .
property 'svn:externals' set on '.'
svn ci -m Created svn:externals
Sending.
Committed revision 974.
svn up
Updating '.':
Fetching external item into 'B':
AB\bin
AB\bin\makecd.rb
AB\bin\mkisofs.exe
Updated external to revision 974.
At revision 974.
svn cp . ..\C
A {some-path}\C
cd ..
svn ci -m Branching
Adding C
Committed revision 975.
cd A
svn propset svn:externals B/D {repo-path}/tools/trunk/makecd .
property 'svn:externals' set on '.'
svn up
Updating '.':
Fetching external item into 'B\D':
AB\D\bin
AB\D\bin\makecd.rb
AB\D\bin\mkisofs.exe
Updated external to revision 975.
Removed external 'B'
Updated to revision 975.
svn add -N B
A B
svn ci -m Moved external to B/D
Sending.
Adding B
Committed revision 976.
cd ..\C
svn merge ..\A
svn: E27: Can't add '{some-path}\svntest\C\B' with URL
'{repo-path}/svn-test/A/B', but with the data from
'{repo-path}/tools/trunk/makecd'
svn: E175002: Error reading spooled REPORT request response
I *think* the problem here is that we're both moving the external
B - B\D and in the same commit also add B. When we then try to
do the merge we first merge the file updates and this detects that
B is already present and under svn controll even though we're
also moving B - B\D through updating the externals directive.
I would count this as user error rather than an svn error but
it feels weird that I can create a revision that cannot be merged
without first doing a svn delete (B) in the destination tree.
Thoughts?
Side note: This merge also managed to cause TortoiseSVN to crash.
Best regards
/Daniel Widenfalk
Re: Error while updating
Guten Tag Ajay Pawar, am Mittwoch, 24. April 2013 um 08:43 schrieben Sie: SVN Admin verify is showing an error called Can't read end of file. There surely is some more output about the details were the error occured and that is needed to suggest anything more. Until now it seems that your repository or at least some revisions are corrupted and you should restore the data from a working backup. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Error while updating
Hello Ajay, I am using this URL from last 3 month, there is no point that URL is wrong. Second thing Server is misconfigured is also not true because other projects are accessible as they are earlier. I do agree that we had installed Visual SVN Server 2.5.7 this Sunday not Monday its working fine then on Tuesday we came up with this error. What exactly have you performed then? An upgrade or a clean install? Please clarify your steps. Please help ASAP as the SVN user are not able to any work. The client-side error you've specified earlier in this thread is not really helpful, you can see it if you attempt to access non-existent repository or the repository is somehow broken. Have you checked the VisualSVN Server log? It should've been the first step of your investigation in fact. So please check the VisualSVN Server log for some clues and hints on the root cause. See Where VisualSVN Server logs are stored http://www.visualsvn.com/support/topic/00028/ for instruction. SVN Admin verify is showing an error called Can't read end of file. What is the *exact* error message? BTW did you manually modify any of internal repository files (e.g. /format, /db/current files)? Did you restore the repository from a backup maybe? Thank you. -- With best regards, Pavel Lyalyakin VisualSVN Team
Re: SVN error while committing
Hello Ajay, Earlier I was facing following issue Can’t parse lock/entries hash file E:\Repositories\OR\db\locks\308\sdfiocvyywt59vxherh and from the mailing list I found a resolution to delete the below file. What solution? What file have you removed? I hope that the repository you work on has a backup at least. Once I had done that I came up with a new error that I posted earlier. When I am trying to look at Path from Repo Browser I see the same error in repo browser also. What error do you see? What do you do to reproduce the error? What's logged to server log then? When I try for Check for modifications command from Tortoise SVN I am not able to see and locked files in the list. Is it the same repository that is mentioned in the other thread about Could not open the requested SVN file system error? I.e. are these issues related? It looks like you are performing some repository maintenance with a crowbar instead of a screwdriver (metaphorically) and it's totally unclear what you did, what errors you get, when you get these errors, when you *started* to get these errors, what's logged to server log etc. A step-by-step description of your actions would also help us to help you. Thank you. -- With best regards, Pavel Lyalyakin VisualSVN Team
Re: Hard-to-understand error message after merge
Daniel Widenfalk daniel.widenf...@iar.se writes:
One of my colleagues got a hard-to-decipher error message after
trying to do a merge (trunk - branch):
svn: E27: Can't add '{some-path}\svntest\C\B' with URL
'{repo-path}/svn-test/A/B', but with the data from
'{repo-path}/tools/trunk/makecd'
svn: E175002: Error reading spooled REPORT request response
After about an hour of head scratching we figured out that something
like the following had occurred:
Thank's for working out the steps!
I *think* the problem here is that we're both moving the external
B - B\D and in the same commit also add B. When we then try to
do the merge we first merge the file updates and this detects that
B is already present and under svn controll even though we're
also moving B - B\D through updating the externals directive.
I would count this as user error rather than an svn error but
it feels weird that I can create a revision that cannot be merged
without first doing a svn delete (B) in the destination tree.
Thoughts?
I've raised issue 4360:
http://subversion.tigris.org/issues/show_bug.cgi?id=4360
--
Certified Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
RE: Error while updating
It's just a clean installation nothing else. -Original Message- From: Pavel Lyalyakin [mailto:pavel.lyalya...@visualsvn.com] Sent: Wednesday, April 24, 2013 1:36 PM To: Ajay Pawar Cc: Andy Levy; users@subversion.apache.org; Sayali S. Kumbhar Subject: Re: Error while updating Hello Ajay, I am using this URL from last 3 month, there is no point that URL is wrong. Second thing Server is misconfigured is also not true because other projects are accessible as they are earlier. I do agree that we had installed Visual SVN Server 2.5.7 this Sunday not Monday its working fine then on Tuesday we came up with this error. What exactly have you performed then? An upgrade or a clean install? Please clarify your steps. Please help ASAP as the SVN user are not able to any work. The client-side error you've specified earlier in this thread is not really helpful, you can see it if you attempt to access non-existent repository or the repository is somehow broken. Have you checked the VisualSVN Server log? It should've been the first step of your investigation in fact. So please check the VisualSVN Server log for some clues and hints on the root cause. See Where VisualSVN Server logs are stored http://www.visualsvn.com/support/topic/00028/ for instruction. SVN Admin verify is showing an error called Can't read end of file. What is the *exact* error message? BTW did you manually modify any of internal repository files (e.g. /format, /db/current files)? Did you restore the repository from a backup maybe? Thank you. -- With best regards, Pavel Lyalyakin VisualSVN Team
Re: Blame/annotate not good enough...
On 23.04.2013 16:29, Thorsten Schöning wrote: Guten Tag Charles Gallo, am Dienstag, 23. April 2013 um 14:22 schrieben Sie: Blame/annotate does exactly what I want, but the client (mumble mumble) wants the info in the actual source code file as comments! I explained that all the info is in blame/SVN, but they actually said the auditors won't see the repository, just the source, and they want to be able to see what changed and by whom. That's why I'm not allowed to delete code, only comment out. Sigh Maybe you should try a different approach: Why do the auditors don't have or want access to the repo? May read-only copy of the repo to access offline a solution? You clearly have never had to deal with the more Neanderthal species of auditor who believe meaningful technological advance stopped about 200 years before Gutenberg. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: Error while updating
On 24.04.2013 07:03, Ajay Pawar wrote: Please help ASAP as the SVN user are not able to any work. This is not a support hotline. Messages like this Please help ASAP are simply rude in this context. Please think twice about what you wrote before sending it. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
RE: Error while updating
I know it's not a hotline but as I am facing the issue from 2-3 days I am too much frustrated. -Original Message- From: Branko Čibej [mailto:br...@wandisco.com] Sent: Wednesday, April 24, 2013 6:13 PM To: users@subversion.apache.org Subject: Re: Error while updating On 24.04.2013 07:03, Ajay Pawar wrote: Please help ASAP as the SVN user are not able to any work. This is not a support hotline. Messages like this Please help ASAP are simply rude in this context. Please think twice about what you wrote before sending it. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: Error while updating
Ajay, Sorry to hear that you are dealing with frustrating Subversion problems. Please understand that the folks who read this forum do, in fact, wish to help you. The problem is simply that without some pretty thorough explanation of what you are experiencing, this task is pretty daunting -- too daunting to justify many of us diverting focused attention your way. (All pain, no gain...) Try to keep in mind that, to a degree, we also share a bit of the frustration of every user who suffers while trying to get Subversion to meet their needs. And if you're feeling frustrated after 2-3 days of your particular Subversion issue, imagine how some of us who've been fielding Subversion problem questions for over a decade must feel. :-) Look, the more information you can give us, the better. Help will always come as soon as possible. It's really kinda up to you to help define possible in this context. -- Mike On 04/24/2013 09:17 AM, Ajay Pawar wrote: I know it's not a hotline but as I am facing the issue from 2-3 days I am too much frustrated. -Original Message- From: Branko Čibej [mailto:br...@wandisco.com] Sent: Wednesday, April 24, 2013 6:13 PM To: users@subversion.apache.org Subject: Re: Error while updating On 24.04.2013 07:03, Ajay Pawar wrote: Please help ASAP as the SVN user are not able to any work. This is not a support hotline. Messages like this Please help ASAP are simply rude in this context. Please think twice about what you wrote before sending it. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
RE: Blame/annotate not good enough...
On Apr 23, 2013, at 15:56, Daniel Shahaf wrote: Ryan Schmidt wrote on Tue, Apr 23, 2013 at 01:45:49 -0500: 3. If you want the actual source code in the repository to contain these comments, then you're talking about several scripts: one that the developers must invoke in place of svn commit to commit their work, which transforms their files in the ways you desire before committing them, and another that runs as a pre-commit hook and verifies that the incoming commit conforms to these requirements (and rejects the commit if not). Or, more simply, developers run 'commit' normally and a post-commit hook appends the blame-comments. Appends the blame-comments to what? Certainly not to the file in the repository because by post-commit time the commit is already finalized. And you wouldn't want to modify the transaction in the pre-commit hook because that would screw up working copies. Are you suggesting the server should make a second commit after every commit to add the blame-comments? That would totally mess up normal use of svn blame, among the other usual problems. I agree. It seems to me that a CI build process should be generating BLAME audit documents for the auditors that could be checked into another repository. The devs should OWN the source, not the auditors! BOb
Re: Blame/annotate not good enough...
On Wed, Apr 24, 2013 at 7:35 AM, Branko Čibej br...@wandisco.com wrote: You clearly have never had to deal with the more Neanderthal species of auditor who believe meaningful technological advance stopped about 200 years before Gutenberg. Can't they at least deal with a web view generated by viewvc or websvn? Or a printout of those views? -- Les Mikesell lesmikes...@gmail.com
Re: merge using same revision number - quick question
Hi Johan, Bob and all We took your suggestion and it still fails in that 1- when we try to merge again at the root level (goals: a- to move subtree merge done previously to the working copy root level so that the past merge can be traced at the root level using svn mergeinfo -show-revs merged) svn merge -c 498 https://test.com/svn/roothttps://test.com/svn/root/src/usr/ext/a.java /path/to/root But when we do a svn status, all other untouched files and folders (unrelated to the revision number) are also touched. svn status -u M 506 src/ap M 506 src/ap/k.java : : We then commit. We performed the above steps for several other revision numbers and still get the same svn status -u output for those files and folders when executing those other subsequent revision numbers. What are we doing wrong ? Thanks all sincerely On Fri, Apr 19, 2013 at 9:36 AM, Bob Archer bob.arc...@amsi.com wrote: Hi All We have a revision that contains a few changed files on the trunk: r345 /usr/ext/a.java /usr/ext/b.java We like to merge this a branch working copy. Can we perform multiple merge svn with the same revision number ? We have a reason to do that; We know it doesnt make sense in this simple example. ie can we have 2 merge svn executions and still produce the same result as a simple merge execution. meaning svn merge -c 345 https://test.com/svn/root/src/usr/ext/a.java svn merge -c 345 https://test.com/svn/root/src/usr/ext/b.java as opposed to svn merge -c 345 https://test.com/svn/root/src/usr/ext Thanks all. The resulting commit would probably be the same... although I expect the merge info would be applied to the files rather than the folder. Give your simple example a try in a test repo. BOb
RE: merge using same revision number - quick question
Hi Johan, Bob and all We took your suggestion and it still fails in that 1- when we try to merge again at the root level (goals: a- to move subtree merge done previously to the working copy root level so that the past merge can be traced at the root level using svn mergeinfo -show- revs merged) svn merge -c 498 https://test.com/svn/root /path/to/root But when we do a svn status, all other untouched files and folders (unrelated to the revision number) are also touched. svn status -u M 506 src/ap M 506 src/ap/k.java : : We then commit. We performed the above steps for several other revision numbers and still get the same svn status -u output for those files and folders when executing those other subsequent revision numbers. What are we doing wrong ? What are the changes to those files? I assume mergeinfo is being elided from all those files? If so, that is something that you want to happen. Once that is done the first time, all your merge info will be in the root folder and you won't see this any more. (Stop top posting!!!) Thanks all sincerely On Fri, Apr 19, 2013 at 9:36 AM, Bob Archer bob.arc...@amsi.com wrote: Hi All We have a revision that contains a few changed files on the trunk: r345 /usr/ext/a.java /usr/ext/b.java We like to merge this a branch working copy. Can we perform multiple merge svn with the same revision number ? We have a reason to do that; We know it doesnt make sense in this simple example. ie can we have 2 merge svn executions and still produce the same result as a simple merge execution. meaning svn merge -c 345 https://test.com/svn/root/src/usr/ext/a.java svn merge -c 345 https://test.com/svn/root/src/usr/ext/b.java as opposed to svn merge -c 345 https://test.com/svn/root/src/usr/ext Thanks all. The resulting commit would probably be the same... although I expect the merge info would be applied to the files rather than the folder. Give your simple example a try in a test repo. BOb
Re: merge using same revision number - quick question
Hi Bob Thanks for your response. What does elided mean ? We do see the revision numbers are moved from eligible to merged in svn mergeinfo after a svn merge and svn commit How do we stop top posting and adhere to the rules ? We're new. Thank you Sincerely On Wed, Apr 24, 2013 at 9:32 AM, Bob Archer bob.arc...@amsi.com wrote: Hi Johan, Bob and all We took your suggestion and it still fails in that 1- when we try to merge again at the root level (goals: a- to move subtree merge done previously to the working copy root level so that the past merge can be traced at the root level using svn mergeinfo -show- revs merged) svn merge -c 498 https://test.com/svn/root /path/to/root But when we do a svn status, all other untouched files and folders (unrelated to the revision number) are also touched. svn status -u M 506 src/ap M 506 src/ap/k.java : : We then commit. We performed the above steps for several other revision numbers and still get the same svn status -u output for those files and folders when executing those other subsequent revision numbers. What are we doing wrong ? What are the changes to those files? I assume mergeinfo is being elided from all those files? If so, that is something that you want to happen. Once that is done the first time, all your merge info will be in the root folder and you won't see this any more. (Stop top posting!!!) Thanks all sincerely On Fri, Apr 19, 2013 at 9:36 AM, Bob Archer bob.arc...@amsi.com wrote: Hi All We have a revision that contains a few changed files on the trunk: r345 /usr/ext/a.java /usr/ext/b.java We like to merge this a branch working copy. Can we perform multiple merge svn with the same revision number ? We have a reason to do that; We know it doesnt make sense in this simple example. ie can we have 2 merge svn executions and still produce the same result as a simple merge execution. meaning svn merge -c 345 https://test.com/svn/root/src/usr/ext/a.java svn merge -c 345 https://test.com/svn/root/src/usr/ext/b.java as opposed to svn merge -c 345 https://test.com/svn/root/src/usr/ext Thanks all. The resulting commit would probably be the same... although I expect the merge info would be applied to the files rather than the folder. Give your simple example a try in a test repo. BOb
RE: merge using same revision number - quick question
On Wed, Apr 24, 2013 at 9:32 AM, Bob Archer bob.arc...@amsi.com wrote: Hi Johan, Bob and all We took your suggestion and it still fails in that 1- when we try to merge again at the root level (goals: a- to move subtree merge done previously to the working copy root level so that the past merge can be traced at the root level using svn mergeinfo -show- revs merged) svn merge -c 498 https://test.com/svn/root /path/to/root But when we do a svn status, all other untouched files and folders (unrelated to the revision number) are also touched. svn status -u M 506 src/ap M 506 src/ap/k.java : : We then commit. We performed the above steps for several other revision numbers and still get the same svn status -u output for those files and folders when executing those other subsequent revision numbers. What are we doing wrong ? What are the changes to those files? I assume mergeinfo is being elided from all those files? If so, that is something that you want to happen. Once that is done the first time, all your merge info will be in the root folder and you won't see this any more. Thanks for your response. What does elided mean ? Elide simple means remove. We do see the revision numbers are moved from eligible to merged in svn mergeinfo after a svn merge and svn commit Great... if you always do your merges from your project root, you won't see this issue again. How do we stop top posting and adhere to the rules ? We're new. Just put your replys at the BOTTOM of your message, or inline as relevant, rather than at the top of your message. BOb
Re: merge using same revision number - quick question
On Wed, Apr 24, 2013 at 9:50 AM, Bob Archer bob.arc...@amsi.com wrote: On Wed, Apr 24, 2013 at 9:32 AM, Bob Archer bob.arc...@amsi.com wrote: Hi Johan, Bob and all We took your suggestion and it still fails in that 1- when we try to merge again at the root level (goals: a- to move subtree merge done previously to the working copy root level so that the past merge can be traced at the root level using svn mergeinfo -show- revs merged) svn merge -c 498 https://test.com/svn/root /path/to/root But when we do a svn status, all other untouched files and folders (unrelated to the revision number) are also touched. svn status -u M 506 src/ap M 506 src/ap/k.java : : We then commit. We performed the above steps for several other revision numbers and still get the same svn status -u output for those files and folders when executing those other subsequent revision numbers. What are we doing wrong ? What are the changes to those files? I assume mergeinfo is being elided from all those files? If so, that is something that you want to happen. Once that is done the first time, all your merge info will be in the root folder and you won't see this any more. Thanks for your response. What does elided mean ? Elide simple means remove. We do see the revision numbers are moved from eligible to merged in svn mergeinfo after a svn merge and svn commit Great... if you always do your merges from your project root, you won't see this issue again. How do we stop top posting and adhere to the rules ? We're new. Just put your replys at the BOTTOM of your message, or inline as relevant, rather than at the top of your message. BOb Hi Bob Thanks again for responding. We would take your suggestion. Could you explain why this is happening to us the unexpected touched files ? Thanks
How to setup a server?
Is there an official Subversion guide to set a subversion server? Thanks, Zé
Re: How to setup a server?
On 04/24/2013 03:18 PM, Zé wrote: Is there an official Subversion guide to set a subversion server? The closest thing to official would be the Version Control With Subversion book (http://svnbook.org/). But don't expect to find an ordered list of steps to setting up a Subversion server, because that's just not the audience for that text. But not to worry! A Google search for guide to setting up a subversion server only returns 1.35 million hits. Surely there's *something* of value out there. If you'd like to avoid setting up the server yourself, you might consider looking into a more turnkey solution uch as CollabNet's Subversion Edge (http://www.collab.net/products/subversion) or WANdisco's uberSVN (http://www.wandisco.com/ubersvn). -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: merge using same revision number - quick question
On Wed, Apr 24, 2013 at 9:50 AM, Bob Archer bob.arc...@amsi.com wrote: On Wed, Apr 24, 2013 at 9:32 AM, Bob Archer bob.arc...@amsi.com wrote: Hi Johan, Bob and all We took your suggestion and it still fails in that 1- when we try to merge again at the root level (goals: a- to move subtree merge done previously to the working copy root level so that the past merge can be traced at the root level using svn mergeinfo -show- revs merged) svn merge -c 498 https://test.com/svn/root /path/to/root But when we do a svn status, all other untouched files and folders (unrelated to the revision number) are also touched. svn status -u M 506 src/ap M 506 src/ap/k.java : : We then commit. We performed the above steps for several other revision numbers and still get the same svn status -u output for those files and folders when executing those other subsequent revision numbers. What are we doing wrong ? What are the changes to those files? I assume mergeinfo is being elided from all those files? If so, that is something that you want to happen. Once that is done the first time, all your merge info will be in the root folder and you won't see this any more. Hi Bob, we're still seeing the problem of unwanted touches of files and directories on new unmerged rev numbers, even after we reapply all merges for all previous already-merged at feature branch root level. We're getting concerned now, wondering if we misunderstood the explanations here. We're using SVN 1.6 Thanks for your response. What does elided mean ? Elide simple means remove. We do see the revision numbers are moved from eligible to merged in svn mergeinfo after a svn merge and svn commit Great... if you always do your merges from your project root, you won't see this issue again.
Re: merge using same revision number - quick question
On Wed, Apr 24, 2013 at 4:25 PM, Z W mpc8...@gmail.com wrote: Hi Bob, we're still seeing the problem of unwanted touches of files and directories on new unmerged rev numbers, even after we reapply all merges for all previous already-merged at feature branch root level. We're getting concerned now, wondering if we misunderstood the explanations here. We're using SVN 1.6 When you do a merge with an SVN 1.6 client, all paths beneath the merge target that have the svn:mergeinfo property set on them will be touched by the merge. Something about the mergeinfo on those items will always be changed. Usually it will just be adding the revisions merged to the ranges stored in the properties. With an SVN 1.7 client, merge will only update the mergeinfo for paths that were affected by the merge. I have not followed the thread, but you can probably remove the svn:mergeinfo property from these files and just start to be sure you only do all future merges from the root of the tree. -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: merge using same revision number - quick question
-Original Message- From: Z W [mailto:mpc8...@gmail.com] Sent: Wednesday, April 24, 2013 4:26 PM To: Bob Archer Cc: Johan Corveleyn; users@subversion.apache.org Subject: Re: merge using same revision number - quick question On Wed, Apr 24, 2013 at 9:50 AM, Bob Archer bob.arc...@amsi.com wrote: On Wed, Apr 24, 2013 at 9:32 AM, Bob Archer bob.arc...@amsi.com wrote: Hi Johan, Bob and all We took your suggestion and it still fails in that 1- when we try to merge again at the root level (goals: a- to move subtree merge done previously to the working copy root level so that the past merge can be traced at the root level using svn mergeinfo -show- revs merged) svn merge -c 498 https://test.com/svn/root /path/to/root But when we do a svn status, all other untouched files and folders (unrelated to the revision number) are also touched. svn status -u M 506 src/ap M 506 src/ap/k.java : : We then commit. We performed the above steps for several other revision numbers and still get the same svn status -u output for those files and folders when executing those other subsequent revision numbers. What are we doing wrong ? What are the changes to those files? I assume mergeinfo is being elided from all those files? If so, that is something that you want to happen. Once that is done the first time, all your merge info will be in the root folder and you won't see this any more. Hi Bob, we're still seeing the problem of unwanted touches of files and directories on new unmerged rev numbers, even after we reapply all merges for all previous already-merged at feature branch root level. We're getting concerned now, wondering if we misunderstood the explanations here. We're using SVN 1.6 Please check the poperties on one of the files. Tell me what the mergeinfo: is prior to your merge and after your merge. Up to this point we were talking about generalities, but we are getting down to specifics now. Also, 1.7 is much less chatty wrt where it adds merge info. BOb Thanks for your response. What does elided mean ? Elide simple means remove. We do see the revision numbers are moved from eligible to merged in svn mergeinfo after a svn merge and svn commit Great... if you always do your merges from your project root, you won't see this issue again.
Re: merge using same revision number - quick question
On Wed, Apr 24, 2013 at 1:30 PM, Mark Phippard markp...@gmail.com wrote: On Wed, Apr 24, 2013 at 4:25 PM, Z W mpc8...@gmail.com wrote: Hi Bob, we're still seeing the problem of unwanted touches of files and directories on new unmerged rev numbers, even after we reapply all merges for all previous already-merged at feature branch root level. We're getting concerned now, wondering if we misunderstood the explanations here. We're using SVN 1.6 When you do a merge with an SVN 1.6 client, all paths beneath the merge target that have the svn:mergeinfo property set on them will be touched by the merge. Something about the mergeinfo on those items will always be changed. Usually it will just be adding the revisions merged to the ranges stored in the properties. With an SVN 1.7 client, merge will only update the mergeinfo for paths that were affected by the merge. I have not followed the thread, but you can probably remove the svn:mergeinfo property from these files and just start to be sure you only do all future merges from the root of the tree. -- Thanks Mark Phippard http://markphip.blogspot.com/ Hi Mark Thanks for the response. We find the mergeinfo property useful in helping us capture all the rev numbers to merge from trunk to branch at the root level. so we're not sure if we like to remove it.
Re: merge using same revision number - quick question
On Wed, Apr 24, 2013 at 1:40 PM, Bob Archer bob.arc...@amsi.com wrote: -Original Message- From: Z W [mailto:mpc8...@gmail.com] Sent: Wednesday, April 24, 2013 4:26 PM To: Bob Archer Cc: Johan Corveleyn; users@subversion.apache.org Subject: Re: merge using same revision number - quick question On Wed, Apr 24, 2013 at 9:50 AM, Bob Archer bob.arc...@amsi.com wrote: On Wed, Apr 24, 2013 at 9:32 AM, Bob Archer bob.arc...@amsi.com wrote: Hi Johan, Bob and all We took your suggestion and it still fails in that 1- when we try to merge again at the root level (goals: a- to move subtree merge done previously to the working copy root level so that the past merge can be traced at the root level using svn mergeinfo -show- revs merged) svn merge -c 498 https://test.com/svn/root /path/to/root But when we do a svn status, all other untouched files and folders (unrelated to the revision number) are also touched. svn status -u M 506 src/ap M 506 src/ap/k.java : : We then commit. We performed the above steps for several other revision numbers and still get the same svn status -u output for those files and folders when executing those other subsequent revision numbers. What are we doing wrong ? What are the changes to those files? I assume mergeinfo is being elided from all those files? If so, that is something that you want to happen. Once that is done the first time, all your merge info will be in the root folder and you won't see this any more. Hi Bob, we're still seeing the problem of unwanted touches of files and directories on new unmerged rev numbers, even after we reapply all merges for all previous already-merged at feature branch root level. We're getting concerned now, wondering if we misunderstood the explanations here. We're using SVN 1.6 Please check the poperties on one of the files. Tell me what the mergeinfo: is prior to your merge and after your merge. Up to this point we were talking about generalities, but we are getting down to specifics now. Hi Bob, thanks for taking the time to respond. do u mean u like us to getprop for mergeinfo ? if not, how do we get that info you like ? So far we only messed with svn mergeinfo --show-rev eligible and merged. Also, 1.7 is much less chatty wrt where it adds merge info. BOb Thanks for your response. What does elided mean ? Elide simple means remove. We do see the revision numbers are moved from eligible to merged in svn mergeinfo after a svn merge and svn commit Great... if you always do your merges from your project root, you won't see this issue again.
Re: merge using same revision number - quick question
On Wed, Apr 24, 2013 at 1:42 PM, Mark Phippard markp...@gmail.com wrote: On Wed, Apr 24, 2013 at 4:40 PM, Bob Archer bob.arc...@amsi.com wrote: Please check the poperties on one of the files. Tell me what the mergeinfo: is prior to your merge and after your merge. Up to this point we were talking about generalities, but we are getting down to specifics now. FWIW, after running the merge just run svn diff. It will show the changes it made to the properties. Hi Mark thanks for responding too. We are trying to automate this process for many files. We simply merge and commit until we hit a Conflict. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Question re: Removing Externals
Guten Tag C M, am Mittwoch, 24. April 2013 um 23:47 schrieben Sie: Any advice/gotchas are most appreciated. You shouldn't capture other's threads. ;-) Besides that, your three question seem to be all the same to me: If you delete svn:externals on the trunk, they aren't available anymore on the trunk only. If you merge the svn:external removal commit to other tags or branches, they will be removed there, too. But only if you merge the change, as with any other change. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Blame/annotate not good enough...
On Wed, Apr 24, 2013 at 8:35 AM, Branko Čibej br...@wandisco.com wrote: On 23.04.2013 16:29, Thorsten Schöning wrote: Guten Tag Charles Gallo, am Dienstag, 23. April 2013 um 14:22 schrieben Sie: Blame/annotate does exactly what I want, but the client (mumble mumble) wants the info in the actual source code file as comments! I explained that all the info is in blame/SVN, but they actually said the auditors won't see the repository, just the source, and they want to be able to see what changed and by whom. That's why I'm not allowed to delete code, only comment out. Sigh Maybe you should try a different approach: Why do the auditors don't have or want access to the repo? May read-only copy of the repo to access offline a solution? You clearly have never had to deal with the more Neanderthal species of auditor who believe meaningful technological advance stopped about 200 years before Gutenberg. -- Brane I have. The key is to get to the auditor, themselves, not the people who interpret what the auditor told the person who took the specs for the person who managed the person who wrote the gant chart for the person the auditor reported person to who interpreted it for your boss. Etc., etc., etc. It's very helpful to speak directly to the person who has to do the audit, and find out what *they* can handle directly. They're often quite reasonable and willing to cooperate in setting up a more efficient transfer of knowledge. It's often the layers in between that make things. strange.
Re: merge using same revision number - quick question
On Wed, Apr 24, 2013 at 11:06 PM, Z W mpc8...@gmail.com wrote: On Wed, Apr 24, 2013 at 1:42 PM, Mark Phippard markp...@gmail.com wrote: On Wed, Apr 24, 2013 at 4:40 PM, Bob Archer bob.arc...@amsi.com wrote: Please check the poperties on one of the files. Tell me what the mergeinfo: is prior to your merge and after your merge. Up to this point we were talking about generalities, but we are getting down to specifics now. FWIW, after running the merge just run svn diff. It will show the changes it made to the properties. Hi Mark thanks for responding too. We are trying to automate this process for many files. We simply merge and commit until we hit a Conflict. Here is an interesting thread from a couple months back, about subtree mergeinfo and how elision currently works: http://svn.haxx.se/users/archive-2012-09/0201.shtml I suggest you read it entirely, it contains a lot of useful information. It's possible that elision (automatically removing the superfluous subtree mergeinfo) won't work in your case. But even if it doesn't, you shouldn't worry too much about it. As others have said: if you use 1.7 clients, merges will be much less chatty (won't touch the subtree mergeinfo, unless the merge actually changes something there). -- Johan
