RE: Strange log path not found behaviour
-Original Message- From: cz02 [mailto:c...@cdak.net] Sent: woensdag 22 mei 2013 12:21 To: users@subversion.apache.org Subject: Strange log path not found behaviour I'm getting a strange log path not found behaviour if I query for multiple revisions: i:\svn log https://server/svn/core/base/trunk -r7114 i:\svn log https://server/svn/core/base/trunk -r6818 r6818 | chris | 2012-05-31 15:27:16 +0200 (Thu, 31 May 2012) | 1 line ## i:\svn log https://server/svn/core/base/trunk -r6818 -r7114 r6818 | chris| 2012-05-31 15:27:16 +0200 (Thu, 31 May 2012) | 1 line ## svn: E160013: '/svn/core/!svn/rvr/7114/trunk' path not found i:\svn log https://server/svn/core/base/trunk -r7114 -r6818 svn: E160013: '/svn/core/!svn/rvr/6818/base/trunk' path not found (I've replaced the actual message with #) The path changed between the two revisions (trunk was moved to base/trunk). Running the log separately is OK but I get an error when combining them - shouldn't they both behave the same way? SVN 1.7.9 server+client on Windows (http://sourceforge.net/projects/win32svn) Yes it should behave the same way, but there were some issues in the implementation. When multiple revisions are passed we try to optimize the way to calculate the actual url to perform the operation on. This case was recently fixed (and then further optimized for performance) towards the soon to be released 1.8. I'm not sure if the relevant fixes are easy to backport to 1.7.x. (cc: pburba) Bert -chris
Re: Use Subversion to Manage Git?
On Tue, May 21, 2013 at 09:55:51PM -0400, Jeffrey Walton wrote: It would be great if it could handle something like: `svn checkout -git ssh://j...@example.com//opt/repo.git`. You could create a git repository on github, and then use Subversion to checkout and commit to that repository (yes, this works, it's a special github feature, which is specific to github.com and isn't open source): https://github.com/blog/1178-collaborating-on-github-with-subversion You could also try subgit: http://subgit.com/
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/21/2013 06:10 PM, Stefan Sperling wrote: Looks like this discussion has entered an infinite loop. ... which is a pity, because certain whole arcs of that loop are arguably off-topic for a users@ list. Design-related discussions really belong on dev@. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: svnserve DoS attack (1.7.8)
On Sun, May 19, 2013 at 11:18:49AM +0200, Stefan Sperling wrote: On Wed, May 15, 2013 at 02:08:57PM +0400, Boris Lytochkin wrote: It is possible to force svnserve daemon to exit using trivial (and valid) TCP session: Thanks for your bug report and patch, Boris. We'll release updates soon that include a fix for this issue. For the record, the fix will be included in 1.6.22, 1.7.9, 1.8.0-rc3, 1.8.0. Our guidelines for reporting security issues are here: http://subversion.apache.org/security/ This issue has been assigned the identifier CVE-2013-2112. It will be added to the public list in due course.
Tags - Symbolic names instead of Directory copy?
Hi all, I'm hoping to have slightly less controversial discussion than the recent branches-as-first-class-objects thread. That topic did, however, touch on tags. As discussed previously, tags as a convention use the same mechanism as the branches convention. The mechanism of svn cp works well for branches. The semantics work as expected (for the most part). That is, the results of the basic operations on the branch work as expected. (checkout, update, commit) In my opinion, the same semantics work less well for tags. My biased mind-set is that a tag is a name identifying a specific version of code (a cross product of branch and revision). In subversion, a directory-path@revision, (e.g., ^/trunk@123) give the correct semantics of a tag. I can checkout the exact version of code. When I am ready to update to a later (or latest) version of the branch, update does the right thing. When I commit, my changes go to the right branch, based on my checkout. But a tag that is the result of an svn cp (e.g., ^/tags/TRUNK-STABLE) does not give the same semantics. * Checkout is fine, I get the right version of the code. * Update gives me the message that my workspace is up to date. So I silently miss the fact that the latest code changes I wanted to pull in are over on trunk, not on this tag I checked out from. I think I'm working on ^trunk@HEAD, but I'm not. * Commit does not send changes the tagged branch -- oh, I thought I had an version of trunk, but my commit does not go to trunk. If I (or my repo admin) properly protects the tags, I get an error and realize I forgot a switch command. If my hook script isn't set up right, it's even worse. I have a change to roll back, when I eventually notice the mistake. Due to those unfortunate semantics, we've do not use tags at all. Whenever we want to specify a version of code, we use branch@revision. We don't have symbolic names, but we do get the right semantics. We have a couple hundred developers and hundreds of branches, but we do without symbolic tags. Yes, I know I'm stupid and that all our developers should be able to understand how to checkout from tags and then switch instead of update, but I think we have saved a lot of grief. (Aside from the fact that I do not have server-side access and can't implement proper hook scripts on our replicated repos.) So, am not saying there is anything fundamentally wrong with how tags work now. They just don't fit our desired semantics, so we don't use them. I am also not saying how a better tag or label feature should be implemented, but for our usage, a symbolic name or symbolic link for a path@revision would be a very useful thing. -Steve
Re: Tags - Symbolic names instead of Directory copy?
On 5/22/2013 4:57 PM, Varnau, Steve (Seaquest RD) wrote: Hi all, I'm hoping to have slightly less controversial discussion than the recent branches-as-first-class-objects thread. That topic did, however, touch on tags. As discussed previously, tags as a convention use the same mechanism as the branches convention. The mechanism of svn cp works well for branches. The semantics work as expected (for the most part). That is, the results of the basic operations on the branch work as expected. (checkout, update, commit) In my opinion, the same semantics work less well for tags. My biased mind-set is that a tag is a name identifying a specific version of code (a cross product of branch and revision). In subversion, a directory-path@revision, (e.g., ^/trunk@123) give the correct semantics of a tag. I can checkout the exact version of code. When I am ready to update to a later (or latest) version of the branch, update does the right thing. When I commit, my changes go to the right branch, based on my checkout. Tags are intended to be immutable. By your convention (not a bad one at all), a tag would be a symbolic name for some part of the repository tree at a specific revision. You could name all your tags this way, e.g. ^/tags/trunk_at_r123 for the above-named peg revision. This would be simpler than asking developers to remember the revision from which they are working, then type in the appropriate syntax. If a tag becomes obsolete (i.e. a fatal error is found in it), just delete it, then create a new tag from the appropriate trunk revision. But a tag that is the result of an svn cp (e.g., ^/tags/TRUNK-STABLE) does not give the same semantics. * Checkout is fine, I get the right version of the code. * Update gives me the message that my workspace is up to date. So I silently miss the fact that the latest code changes I wanted to pull in are over on trunk, not on this tag I checked out from. I think I'm working on ^trunk@HEAD, but I'm not. * Commit does not send changes the tagged branch -- oh, I thought I had an version of trunk, but my commit does not go to trunk. If I (or my repo admin) properly protects the tags, I get an error and realize I forgot a switch command. If my hook script isn't set up right, it's even worse. I have a change to roll back, when I eventually notice the mistake. Usually only the build system (or developers trying to fix a specific bug) will check out a tag. Developers modifying code would not check out tags. Updating a tag, if it is immutable, is expected to be a no-op. A pre-commit hook would prevent commits to the tag. Due to those unfortunate semantics, we've do not use tags at all. Whenever we want to specify a version of code, we use branch@revision. We don't have symbolic names, but we do get the right semantics. We have a couple hundred developers and hundreds of branches, but we do without symbolic tags. Yes, I know I'm stupid and that all our developers should be able to understand how to checkout from tags and then switch instead of update, but I think we have saved a lot of grief. (Aside from the fact that I do not have server-side access and can't implement proper hook scripts on our replicated repos.) You could have the same problem by checking out a branch and then switching to trunk. Which set of updates are you going to get? Which set of updates are going to be committed, and to where? I avoid that kind of confusion by not using svn switch. But I work in a simpler repository structure (a small number of developers with most development on trunk). It sounds like the root of your problem is not being able to implement a proper pre-commit hook to make the tags directory immutable. Tools are supposed to help perform your tasks more easily and reliably, and help you catch the mistakes you will inevitably make. If you aren't allowed to configure the tool to do this, it's not the tool's fault (or the concept). A new programmer recently asked me when she would stop making stupid mistakes. I replied never - I spend half of my time making mistakes and half of my time fixing them. After 1,000,000+ lines of code, I still make stupid mistakes. That's what testing is all about. So, am not saying there is anything fundamentally wrong with how tags work now. They just don't fit our desired semantics, so we don't use them. I am also not saying how a better tag or label feature should be implemented, but for our usage, a symbolic name or symbolic link for a path@revision would be a very useful thing. I'd say tags don't fit your repository configuration. See if you can get a pre-commit hook that blocks modifications to the tags directory tree within the repository. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: Tags - Symbolic names instead of Directory copy?
On 23.05.2013 04:33, David Chapman wrote: On 5/22/2013 4:57 PM, Varnau, Steve (Seaquest RD) wrote: So, am not saying there is anything fundamentally wrong with how “tags” work now. They just don’t fit our desired semantics, so we don’t use them. I am also not saying how a better tag or label feature should be implemented, but for our usage, a symbolic name or symbolic link for a path@revision would be a very useful thing. I'd say tags don't fit your repository configuration. See if you can get a pre-commit hook that blocks modifications to the tags directory tree within the repository. I'm confused ... why would you need a special pre-commit hook for something like that? I would expect access control to be good enough. Just make the tags tree in the repository read-only for most users. (N.B., having actually immutable tags would be a nice feature, but they're not required to solve your problem.) -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: Tags - Symbolic names instead of Directory copy?
On 5/22/2013 7:56 PM, Branko Čibej wrote: On 23.05.2013 04:33, David Chapman wrote: On 5/22/2013 4:57 PM, Varnau, Steve (Seaquest RD) wrote: So, am not saying there is anything fundamentally wrong with how “tags” work now. They just don’t fit our desired semantics, so we don’t use them. I am also not saying how a better tag or label feature should be implemented, but for our usage, a symbolic name or symbolic link for a path@revision would be a very useful thing. I'd say tags don't fit your repository configuration. See if you can get a pre-commit hook that blocks modifications to the tags directory tree within the repository. I'm confused ... why would you need a special pre-commit hook for something like that? I would expect access control to be good enough. Just make the tags tree in the repository read-only for most users. (N.B., having actually immutable tags would be a nice feature, but they're not required to solve your problem.) Access controls implies more than what the original poster was asking. Right now anyone can make a tag in his development environment simply by recalling the revision number. Access controls could work and are a reasonable suggestion in many cases. I tend not to think of them because I usually work in more-open environments where anyone can commit. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: Tags - Symbolic names instead of Directory copy?
On Wed, 22 May 2013 19:33:33 +, David Chapman wrote: ... Usually only the build system (or developers trying to fix a specific bug) will check out a tag. Developers modifying code would not check out tags. Unless they are using externals. Letting external point to a non-tag thing isn't good idea (because the tags you make of your project wouldn't fix the externals to a tagged version). And then you run into some workflow turbulence when you start modifying within the externals. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800
svnadmin upgrade output message i18n issue
os: windows encoding:GBK ( chcp 936 ) The svnadmin upgrade command output message first line encoding issue(UTF-8 show in GBK),But the second line is right encoding! 宸插��寰���搴瀹���?璇风�锛绾х�搴��介��瑕�涓�娈垫�堕�?.. 完成升级。 if change console encoding to UTF-8 (chcp 65001),output message is : Repository lock acquired. Please wait; upgrading the repository may take some time... Upgrade completed.
