is this a bug ?
I got no reaction on freenode#svn, so here goes : This looks like a bug in 1.6.12 to me : for a subdirectory with its .svn/ removed a 'svn up --force .' in its parent does not recreate it where 'svn up --force dirname' does -- Hans
Questions on migrating SVN (and Trac) to a Google Compute Engine instance
Greetings. My employer has put me on a project of moving our SVN and Trac servers from the old Windows Server 2003 box on which they're currently running over to a Google Compute Engine instance. To that end, I've set up the instance using Bitnami's canned Trac image, which includes SVN 1.9.5 (r1770682) and Trac 1.0.15 (our old SVN server is 1.5.0, r31699, and our old Trac server is 1.0). I've got a test repository set up, and I've arranged access via both https: and svn+ssh: protocols, which I then spent a few hours testing from Eclipse. But I'm not the one who set up the original SVN and Trac environments in the first place, and so what little I know about administration on these products is what I've picked up over the past few weeks. Now, Trac's wiki page on the process of a dual migration, https://trac.edgewall.org/wiki/TracMigrate seems to be pretty straightforward on the subject of migrating Trac, but the section on migrating SVN is not so. They recommend setting up a "pre-revprop-change" script with nothing in it but the initial "shebang", for each target repository, and then using "svnsync" to migrate the repositories. It also assumes the existence of an "svnsync" user-ID on the target system, which (at least assuming it's an operating system user-ID) we don't currently have. Everything else I've read, especially The SVN Book, says to use "svnsync" only for mirroring, and instead migrate using some combination of "svnadmin dump," "svnadmin load," "svnrdump," and "svnrload." I'm not seeing a lot about copying configuration files or hook scripts. Is that just a matter of sending them over? And I don't quite understand how this whole business impacts the authors of commits. Does SVN care whether the author of a commit is a user known to SVN or to the operating system? I've already copied an "authz" file from one of the existing repositories into the test repository, and given the current users Apache user-IDs and passwords, but that's all, so far. -- James H. H. Lampert Touchtone Corporation
Re: Questions on migrating SVN (and Trac) to a Google Compute Engine instance
On 7/27/17, 11:15 PM, Ryan Schmidt wrote: Sounds plausible. An empty pre-revprop-change hook script would allow any revprop change, which you may not want. It's probably possible to write a more-specific script that would allow only the changes svnsync needs and disallow others. . . . svnsync is probably best, since it allows you to easily incrementally mirror a live read/write repository to another server. It can be slow but once it's done it makes it very quick to switch from the old server to the new one with minimal downtime. Some of the other methods require you to make the source repository read-only or take it offline for the duration of the migration, which could take hours or days depending on how large your repository is. . . . and Arwin and Nico said similar things. Thanks, Ryan, Arwin, and Nico. It took a bit of futzing around, but as I type this, I'm replicating a repository (the smallest and currently least-active one). It took me a while to realize that the hooks with .tmpl extensions were templates, not live hooks, and I was right on the verge of asking for help when I looked at the instructions again, and realized that instead of setting up the required null hook, I'd overwritten a template (DUH!) -- JHHL
Off-topic about the List itself: Does it handle posts from DMARC-enabled senders well?
I'm in the process of setting up DMARC for my company's domain. Does this List either rewrite headers on posts from DMARC-enabled senders, or otherwise do something to ensure that posts from DMARC-enabled senders are not mis-identified by recipients as spoofed? -- James H. H. Lampert Touchtone Corporation
Subversion times out when checking in several files
I have a subversion repository that has worked fine for years. When I now try to check in several changed files, it times out (apparently when the network connection gives up after several minutes). I can check in some of the files individually, including every single one in a subset that failed when done at once. svnadmin verify passes. I am using a direct connection to the server (i.e. svn://, not svn+ssh:// ). The message is Transmitting file data ..svn: Commit failed (details follow): svn: Can't write to connection: Connection timed out I tried starting the server as svnserve -r /home/svn/SVN/repos --foreground -X in the hope it would say something helpful, but it doesn't (it just sits there as if it never received the connection at all). It still carries out simple checkins correctly (and terminates after every one). The client is 1.4.6 (default on Ubuntu Hardy) and the server is 1.5.4 (default on Ubuntu Jaunty). It runs over a slowish VPN which does not appear to molest TCP connections much if at all. What might I be doing wrong, and where do I start debugging the problem? Many thanks for any help.
Re: Subversion times out when checking in several files
> > I'd suspect the VPN first. They normally encapsulate packets, reducing the > maximum size for the original data which must then be fragmented if it was > already at the maximum packet size. If the sender sets the DF (don't > fragment) bit, which is often done unnecessarily, it will fail and have to > try to determine the largest packet size that will go through. And this > will fail if intermediate firewalls block the required ICMP packats as they > usually do in situations where VPNs are needed. You could try setting the > MTU lower on the client to work around the problem. > Many thanks. It appears that was the problem. I was inclined to blame the horrible Cisco AnyConnect VPN myself, but i) icmp echo-requests get through fine, and ii) ssh/www/samba work apparently correctly over it. (It would still be horrible even if it turns out to be some firewall's fault :-) ) For others, the command to try under Linux is something like sudo ifconfig eth0 mtu 300, You should probably use a higher value than 300 once it works (1200?). Once again, many thanks for your help.
add * ignores new files in subdirectories.
Subversion Dev team: Thanks for all your hard work. I just began using subversion and it is great. Among other things, it is fast. One complaint. I'm using a Linux system, fyi. As a new user it was my expectation that 'svn add *' called from within the root of my version-controlled root directory would result in *all* changes that had been made within the file system to be scheduled for inclusion on the next commit. Instead, it ignored a whole raft of new files that were buried in subdirectories. It took me a while of poking around to find this out. The behavior I expected was that "svn add *" would schedule a snapshot of the entire directory tree. Of course, to actually make this happen, I had to use the "svn add * --force" option. It's also worth noting that the option "svn add * --depth infinity" also did not add the files that were buried in the subdirectores; they were not added to be included on the next commit. Why would you have subversion skip a bunch of files? That makes no sense. The "import" command conversely, adds all the files in all the subdirectories, when a new directory is first brought under version control. It seems to me, the default behavior should be the obvious behavior. Or maybe there is more that I don't yet understand. If so, I would like to hear. Thanks. It is great software. David Heitzman -- Life moves on, whether we act as cowards, or heroes.
SVN patch issue with property changes
Hi Team, I have a patch with svn property changes as below: dipuh@contrail-ubm-MADHUS:/tmp/tests$ svn diff xpathleak.py Index: xpathleak.py === --- xpathleak.py (revision 950359) +++ xpathleak.py (working copy) @@ -4,25 +4,15 @@ libxml2.debugMemory(True) expect="""--> Invalid expression ---> xmlXPathEval: evaluation failed --> Invalid expression ---> xmlXPathEval: evaluation failed """ err="" def callback(ctx, str): Property changes on: xpathleak.py ___ Modified: svn:executable ## -0,0 +1 ## +* <<<<<<<- Yes, there is a change, value * added to property svn:executable \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Now I generated the patch and applied it on another copy of the same branch. dipuh@contrail-ubm-MADHUS:/tmp/tests$ svn diff xpathleak.py >/tmp/mypatch dipuh@contrail-ubm-MADHUS:/tmp/apply$ svn patch /tmp/mypatch UC xpathleak.py > rejected hunk ## -0,0 +1,1 ## (svn:executable) Summary of conflicts: Property conflicts: 1 The patch is rejected without changing the property. The destination file already has svn:executable property present in it. But the value is empty. Ideally, if the patch was applied properly, the value should have been changed to "*". After little bit of googling, I found the below link which looks like a similar issue. https://jira.atlassian.com/browse/CRUC-6114?src=confmacro SVN Version : 1.8.11 I understand that the latest svn clients add * as the value of svn:executable property. However, if we generate a patch out of this and apply on an existing file, `svn patch` is not able to identify that there is a property change from ‘null’ to ‘*’. Could you please check if this is a bug? Thanks, Dipu H
Re: SVN patch issue with property changes
Hi Johan, Thanks for getting back. I tried to patch with svn 1.9 and 1.10. Still the same error. root@contrail-ubm-dipuh:/tmp/tests# svn --version -q 1.10.0 root@contrail-ubm-dipuh:/tmp/tests# svn patch /tmp/patch Cxpathleak.py > rejected hunk ## -0,0 +1,1 ## (svn:executable) Summary of conflicts: Property conflicts: 1 root@contrail-ubm-dipuh:/tmp/tests# cat /tmp/patch Index: xpathleak.py === --- xpathleak.py(revision 951471) +++ xpathleak.py(working copy) Property changes on: xpathleak.py ___ Modified: svn:executable ## -0,0 +1 ## +* \ No newline at end of property root@contrail-ubm-dipuh:/tmp/tests# Looks like svn is not able to properly handle the svn:executable property changes via patch. Thanks, On 6/28/18, 1:18 PM, "Johan Corveleyn" wrote: On Wed, Jun 27, 2018 at 1:07 PM, Dipu H wrote: > Hi Team, > > I have a patch with svn property changes as below: > > dipuh@contrail-ubm-MADHUS:/tmp/tests$ svn diff xpathleak.py > Index: xpathleak.py > === > --- xpathleak.py (revision 950359) > +++ xpathleak.py (working copy) > @@ -4,25 +4,15 @@ > libxml2.debugMemory(True) > > expect="""--> Invalid expression > ---> xmlXPathEval: evaluation failed > --> Invalid expression > ---> xmlXPathEval: evaluation failed > """ > err="" > def callback(ctx, str): > > Property changes on: xpathleak.py > ___ > Modified: svn:executable > ## -0,0 +1 ## > +* <<<<<<<- Yes, there is a change, value * added to property > svn:executable > \ No newline at end of property > Added: svn:mime-type > ## -0,0 +1 ## > +text/plain > \ No newline at end of property > > > > Now I generated the patch and applied it on another copy of the same branch. > > dipuh@contrail-ubm-MADHUS:/tmp/tests$ svn diff xpathleak.py >/tmp/mypatch > > dipuh@contrail-ubm-MADHUS:/tmp/apply$ svn patch /tmp/mypatch > UC xpathleak.py >> rejected hunk ## -0,0 +1,1 ## (svn:executable) > Summary of conflicts: > Property conflicts: 1 > > The patch is rejected without changing the property. The destination file > already has svn:executable property present in it. But the value is empty. > Ideally, if the patch was applied properly, the value should have been > changed to "*". > > > After little bit of googling, I found the below link which looks like a > similar issue. > > https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.atlassian.com_browse_CRUC-2D6114-3Fsrc-3Dconfmacro&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=R5PFHc5rDhpXLKW9uD5GLI0W5asiYkw8WhxwHr2VyEY&m=2Csq4fBQTlRsi0n-Yy6XoE4sy-DbLVwSjkHoUJTGnGc&s=GOnZyVv3lNp9RPBWISwcxT6lg-OydhkL7p29RsFJcDo&e= > > SVN Version : 1.8.11 > > > > I understand that the latest svn clients add * as the value of > svn:executable property. However, if we generate a patch out of this and > apply on an existing file, `svn patch` is not able to identify that there is > a property change from ‘null’ to ‘*’. Could you please check if this is a > bug? SVN 1.8.11 is very old (version 1.8.x is actually end-of-life now [1]). Can you test with a 1.10 client to see if it shows the same behaviour? [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__subversion.apache.org_docs_release-2Dnotes_1.10.html-23svn-2D1.8-2Ddeprecation&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=R5PFHc5rDhpXLKW9uD5GLI0W5asiYkw8WhxwHr2VyEY&m=2Csq4fBQTlRsi0n-Yy6XoE4sy-DbLVwSjkHoUJTGnGc&s=1HQYS3C3zQt48pqpi3F0MrOObkTvG9TllltanmlCLTs&e= -- Johan
Re: SVN patch issue with property changes
Hi Daniel, Thanks for the update. Yes, I have many files in the repository with "svn:executable" value set to "null". This is a very old repository, may be created using a very older version of svn. Older clients might have added the property without a value. root@contrail-ubm-dipuh:/tmp/tests# svn pl xpathleak.py Properties on 'xpathleak.py': svn:executable root@contrail-ubm-dipuh:/tmp/tests# svn pg svn:executable xpathleak.py root@contrail-ubm-dipuh:/tmp/tests# Thanks, Dipu H On 6/28/18, 8:13 PM, "Daniel Shahaf" wrote: Dipu H wrote on Thu, 28 Jun 2018 14:24 +: > Looks like svn is not able to properly handle the svn:executable > property changes via patch. Works for me: [[[ % svnadmin create r % svn co -q file://`pwd`/r wc % cd wc % touch iota % svn add -q iota % svn ci -q -m add % svn up -q % svn ps -q svn:executable yes iota % svn diff > foo % svn revert -q iota % svn patch -q foo % svn diff Index: iota === --- iota(revision 1) +++ iota(working copy) Property changes on: iota ___ Added: svn:executable ## -0,0 +1 ## +* \ No newline at end of property ]]] You mentioned earlier that svn:executable was present with an empty value. Is that really the case? If it is --- which would be surprising, as it's supposed to be an impossible state --- it would explain why you got a conflict.
Re: SVN patch issue with property changes
Hi Philip, It is a conflict. Values didn’t change after applying the patch. root@contrail-ubm-dipuh:/tmp/tests# svn patch /tmp/patch Cxpathleak.py > rejected hunk ## -0,0 +1,1 ## (svn:executable) Summary of conflicts: Property conflicts: 1 root@contrail-ubm-dipuh:/tmp/tests# svn diff xpathleak.py root@contrail-ubm-dipuh:/tmp/tests# Thanks, Dipu H On 6/28/18, 8:49 PM, "Philip Martin" wrote: Daniel Shahaf writes: > You mentioned earlier that svn:executable was present with an empty > value. Is that really the case? If it is --- which would be surprising, > as it's supposed to be an impossible state --- it would explain why you > got a conflict. The normalization of svn:executable values is implemented in the client. If some client chooses not to implement that normalization the backend will store any value given. Should the svn client silently merge '' and '*' for svn:executable values or should it be a conflict? I favour the conflict but I can see arguments for a silent merge. -- Philip
reuse of tag to keep stable URLs?
I am trying to get beyond my rather simple use of svn and would like some advice. My goal is to have two releases of a package available, one bleeding edge and the other stable. I want to keep the URLs to both releases stable. This seems like a reasonably common thing that one would want, but google has failed to find this discussed (probably because I am using the wrong lingo to describe what I want.) Anyway, I can see two ways to implement this: 1) Keep the bleeding-edge release in the trunk and use a tagged version for the stable release. When I am ready to make a new stable release, I delete the stable tagged release from the repository and then copy the trunk reusing the same tag name. 2) keep the stable release as the trunk and work on the bleeding-edge release as a branch. When I am ready to make a new stable release, I use merge --reintegrate and commit to update the stable release and then delete and recreate the bleeding-edge branch. Option 2 seems to be the way that svn is designed to be used, but is more complex. I guess it is more robust, if someone commits a change to the stable. Are there any other reasons to go that route? Is there an even better choice? Brian
Re: reuse of tag to keep stable URLs?
Thanks very much. (BTW, your english here was just about perfect.) On Jan 12, 2010, at 5:06 AM, Andrey Repin wrote: Greetings, Brian H. Toby! I am trying to get beyond my rather simple use of svn and would like some advice. My goal is to have two releases of a package available, one bleeding edge and the other stable. I want to keep the URLs to both releases stable. This seems like a reasonably common thing that one would want, but google has failed to find this discussed (probably because I am using the wrong lingo to describe what I want.) Anyway, I can see two ways to implement this: 1) Keep the bleeding-edge release in the trunk and use a tagged version for the stable release. When I am ready to make a new stable release, I delete the stable tagged release from the repository and then copy the trunk reusing the same tag name. 2) keep the stable release as the trunk and work on the bleeding-edge release as a branch. When I am ready to make a new stable release, I use merge --reintegrate and commit to update the stable release and then delete and recreate the bleeding-edge branch. Option 2 seems to be the way that svn is designed to be used, but is more complex. I guess it is more robust, if someone commits a change to the stable. Are there any other reasons to go that route? Is there an even better choice? Nope. It's the case 1. You branching stable version to tags, leaving /trunk as your workplace. Could as well copy to branches: copy /trunk to /tag/ delete /branch/stable copy /tags/ to /branch/stable /trunk is your mainstream, especially if you're working mainly alone on the project. If you need space for experimenting, or if you need to backport some changes from trunk to stable, you create a new branch from stable branch, port whatever you want to it, then merge it back to stable and delete the one you used to backport. -- WBR, Andrey Repin (anrdae...@freemail.ru) 12.01.2010, <14:00> Sorry for my terrible english... **** Brian H. Toby, Ph.D.office: 630-252-5488 Senior Physicist/Section Head for Scientific Software Advanced Photon Source 9700 S. Cass Ave, Bldg. 401/B4192work cell: 630-327-8426 Argonne National Laboratory Argonne, IL 60439-4856 e-mail: brian dot toby at anl dot gov "We will restore science to its rightful place, and wield technology's wonders... We will harness the sun and the winds and the soil to fuel our cars and run our factories... All this we can do. All this we will do."
Feature Request: svn status should provide a conflict check functionality via exit code
Hello ! i missing an easy way to check a local checkout for conflicts. Currently I'm grep the output of svn status for the existence of the phrase „Summary of conflicts“. This is ugly: - needs LC_ALL=C ensurance - may break in future versions of my the svn client. A better way would to have an --check-conflict option which would ensure an non-zero exit code if any conflict is detected. Best Reagrads, H.-Dirk Schmitt
Missing LOCALE in post-commit hook leads to weird behaviour of `svnlook log` with unicode characters – broken transliterations
I found a very weird behaviour of `svnlook log` that IMHO is a bug (or
at least a serious missing documentation issue).
Introduction
Consider a log message like: 'Unicode Test → ø ÄÖÜ'
`svnlook log` invoked in a normal terminal session shows the proper
content.
This works because the environment is set to 'en_US.UTF-8'.
Now start to play - `env LC_ALL=C.UTF-8 svnlook log` also shows a
correct result.
Problem
---
But falling back to `env LC_ALL=C svnlook log` I got a very flawed
result:
Unicode Test {U+2192} {U+00F8} AOU
→ and ø are replaced with there code description
The German Umlaut chars are translitterated in a very uncommon way.
In the old ASCII/type-writer days Ä was translitterated in Ae (Ö → Oe,
…)
Why is this behaviour not a cosmetic problem.
-
Consider a post-commit hook fetching the commit message with `svnlook
log`.
Purpose is to postprocess the log message content, e.g. append to
bugzilla issues.
The actual setup is svn+apache2 and a bash script as post commit hook.
The machine locatle as reported by `localectl`: System Locale:
LANG=en_US.utf8
All the commit messages content transfered is broken as described
above.
This happens because the post-commit hook is running with a very
reduced set of environment variables:
PWD=/
SHLVL=1
Especially `LC_ALL` is not set which is eqivalent to `LC_ALL=C`.
Suggested Mitigation/Fixing
---
1. Subversion should ensure that the system locale is forwarded to the
post-commit hook.
2. `svnlook` shoud support the `--encoding` switch
3. German Umlaute (and surely some other national characters in the 8-
bit range) shouldn't translittered in a different
way as unicode characters (see ø / {U+00F8}).
PS: Google et. al. haven't shown that this issue is well documented.
Missing LOCALE in post-commit hook leads to weird behaviour of `svnlook log` with unicode characters – broken transliterations
I found a very weird behaviour of `svnlook log` that IMHO is a bug (or
at least a serious missing documentation issue).
Introduction
Consider a log message like: 'Unicode Test → ø ÄÖÜ'
`svnlook log` invoked in a normal terminal session shows the proper
content.
This works because the environment is set to 'en_US.UTF-8'.
Now start to play - `env LC_ALL=C.UTF-8 svnlook log` also shows a
correct result.
Problem
---
But falling back to `env LC_ALL=C svnlook log` I got a very flawed
result:
Unicode Test {U+2192} {U+00F8} AOU
→ and ø are replaced with there code description
The German Umlaut chars are translitterated in a very uncommon way.
In the old ASCII/type-writer days Ä was translitterated in Ae (Ö → Oe,
…)
Why is this behaviour not a cosmetic problem.
-
Consider a post-commit hook fetching the commit message with `svnlook
log`.
Purpose is to postprocess the log message content, e.g. append to
bugzilla issues.
The actual setup is svn+apache2 and a bash script as post commit hook.
The machine locatle as reported by `localectl`: System Locale:
LANG=en_US.utf8
All the commit messages content transfered is broken as described
above.
This happens because the post-commit hook is running with a very
reduced set of environment variables:
PWD=/
SHLVL=1
Especially `LC_ALL` is not set which is eqivalent to `LC_ALL=C`.
Suggested Mitigation/Fixing
---
1. Subversion should ensure that the system locale is forwarded to the
post-commit hook.
2. `svnlook` shoud support the `--encoding` switch
3. German Umlaute (and surely some other national characters in the 8-
bit range) shouldn't translittered in a different
way as unicode characters (see ø / {U+00F8}).
PS: Google et. al. haven't shown that this issue is well documented.
Re: Missing LOCALE in post-commit hook leads to weird behaviour of `svnlook log` with unicode characters – broken transliterations
Stefan Sperling : > On Sat, Jan 27, 2018 at 06:35:17PM +0100, H.-Dirk Schmitt wrote: > > All the commit messages content transfered is broken as described > > above. > > > > This happens because the post-commit hook is running with a very > > reduced set of environment variables: > >PWD=/ > >SHLVL=1 > > See http://subversion.apache.org/docs/release-notes/1.8.html#hooks-en > v > and http://subversion.apache.org/docs/release-notes/1.8.html#mod-dav- > svn-utf8 Johan Corveleyn : > This is documented in the official documentation (the "SVN Book"): > [...] > (see the first sentence there: "By default, Subversion executes hook > scripts with an empty environment—that is, no environment variables > are set at all, not even $PATH (or %PATH%, under Windows).") OK - My „Postscriptum“ was not correct - my apologies. But still valid are the the points: - Broken transliteration of German Umlaut. - Subversion is ignoring the machine locate settings which should normally the default if not overwritten in the Environment. This is a considerable bad behaviour for a linux/unix application. -- Signature H.-Dirk Schmitt H.-Dirk Schmitt Dipl.Math. eMail:dirk.schm...@computer42.org mobile:+49 177 616 8564 phone: +49 2642 99 41 14 fax: +49 2642 99 41 15 Schillerstr. 42, D-53489 Sinzig pgp: http://www.computer42.org/~dirk/OpenPGP-fingerprint.html
Cannot view branch contents
History, We have SVN repositories on an older server. One of our root projects has a branch titled "tag" which all users can see and expand the contents of. I have copied this repository to a new server. The contents of "tag" cannot be seen by any users except one. Yet, all other branches can be viewed/expanded. Any thoughts? I have researched through the pages and have not found anything like the situation that I described. v/r, Jim CTR Jim Walker DSS Configuration Manager, J864 smime.p7s Description: S/MIME cryptographic signature
