RE: svnlook cat seems to swallow byte order marks
The md5 sum of the working copy and the output of svnlook cat are the same. hexdump shows that the byte order mark is actually there. It seems that the shell constructs i used stripped off the bom. Thank you very much for your help, Michael and Daniel. Alex
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) -chris
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 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 R&D) 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 R&D) 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 R&D) 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 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.
Re: Tags - Symbolic names instead of Directory copy?
Guten Tag Varnau, Steve (Seaquest R&D), am Donnerstag, 23. Mai 2013 um 01:57 schrieben Sie: > 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”). I don't see the point, as you already know that it's not handled that way in Subversion and you need to make the same conclusions for tags and branches. > In > subversion, a directory-path@revision, (e.g., ^/trunk@123) give the > correct semantics of a tag. Simply use them that way, like you said for branches. > But a “tag” that is the result of an svn cp (e.g., > ^/tags/TRUNK-STABLE) does not give the same semantics. Because from my understanding you compare two things which have nothing to do with each other: One is how branches and tags are created, both the same way, but the other is what happens afterwards to each. As branches and tags are technically the same, only differing by convention, they of course work equally and therefore need to share 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. Only if it is update, meaning no one ever committed anything to your tag. If commits were made, your working copy would not be up to date anymore, of course. It sounds to me like you compare branches with per convention immutable tags to come to the conclusion that both have different semantics. But that's not the case, just a result of your immutable tags convention. > 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. Because with checking out a tag and keeping it immutable you want that tag and not trunk. Or what's the reason for checking out that special tag at all? Especially if you know it's immutable, if it wouldn't be immutable you of course would get new commits. > 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. I may be misunderstanding you but I think this is wrong. Commits of course always go to the directory you checked out, in your case tags/TRUNK-STABLE. If you wanted to work on trunk than I don't know why you checked out tags/TRUNK-STABLE at all? And what's the difference to branches? If you check out branches/someFeature your committs wil always go to branches/someFeature and not branches/branchWhichSomeFeatureBasedOn or trunk or whatever. There's no difference between branches and tags, that's what the last thread was about. > If I (or my repo admin) properly > protects the tags, I get an error and realize I forgot a switch > command. If you wouldn't protect your tags you would get the updates you were missing before. What do you really want, immutable tags or not? > 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. branch@revision-semantics would perfectly well work with immutable tags, the problem is that you expect updates and commits for some reason. > 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, Why would you want to checkout immutable tags at all? And how do you work with non immutable branches? Why are your developers able to switch from non immutable branches, but not from immutable or non immutable, whatever you like, tags? That sounds a bit weird to me, but I may simply didn't understand your point. > 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.) Does this mean that the problem with invalid hook scripts denying commit access to tags which you mentioned earlier doesn't exist and you are able to commit to tags and getting updates, which you mentioned as missing before and all that stuff? :-) I'm a bit confused... > So, am not saying there is anything fundamentally wrong with how > “tags” work now. Of course it's not as they work like branches and branches seem to work for you. > They just don’t fit our desired semantics, I didn't understand the semantics you want from your description, sorry. > 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. But you could simply use tags/TRUNK-STABLE@someRev or wouldn't need @someRev at all if your tags are immutable after creation. 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.
