svn:eol-style does not work on update
Hello, i've enabled enable-auto-props=yes and *.php=svn:eol-style:native on linux... but when i "svn update" i still have msdos linefeeds in the php file... even when i delete the php file before updating.. i am using only the client... no idea where or what the server is... Dirk
svn:eol-style does not work on update
Hello, i've enabled enable-auto-props=yes and *.php=svn:eol-style:native on linux... but when i "svn update" i still have msdos linefeeds in the php file... even when i delete the php file before updating.. i am using only the client... no idea where or what the server is... Dirk
Re: svn:eol-style does not work on update
Tino Schwarze wrote: > Hi Dirk, > > On Tue, Mar 30, 2010 at 04:05:12PM +0200, Dirk wrote: > >> i've enabled >> >> enable-auto-props=yes >> >> and >> >> *.php=svn:eol-style:native >> >> on linux... >> >> but when i "svn update" i still have msdos linefeeds in the php file... even >> when i delete the php file before updating.. > > The auto-props only work for add and import. You need to set them > manually for files which are already there. It should be possible to set > them after checkout: > svn propset svn:eol-sty.e native yourfile.php > > Then commit. Maybe you need to delete the file and "svn update" it again > to make SVN check out a fresh copy - I'm not sure how it behaves. > > HTH, > > Tino. > Thanks. :)
Re: svn:eol-style does not work on update
> There is a svn_apply_autoprops as part of the subversion distribution > (in contrib, I think), which will apply your current auto props to a > working copy. > > My current copy of that script is attached - needs python. > > I use it a lot, and it works well for me. > Tony Butt > CEA Technologies Thanks. I already tried Tino's tip and it worked. The msdos linefeeds are gone permanently.
unsubscribe
unsubscribe
unsubscribe
question
how can i unsubscribe from this list?
Re: question
Idiot Pablo Beltran Labarta wrote: > Hu. reading the documentation? > > 2010/4/2 Dirk > >> how can i unsubscribe from this list? >> >
Possible bug: --stop-on-copy stops too early
Hi, I'm trying to get the base revision of a branch using "svn log --stop-on- copy". However, the output of this command stops a couple of revisions too early: svn log -v https://sdmpudpagport.sdm.de/pu/dpagpalis/svn/repository/software/branches/dhe_oracle_tablespaces_fuer_appcom r1954 | hardt | 2011-05-19 13:51:17 +0200 (Thu, 19 May 2011) | 1 line Changed paths: D /PALISNC A /software (from /PALISNC:1953) renamed software statt PALISNC r1950 | dheinric | 2011-05-18 09:02:13 +0200 (Wed, 18 May 2011) | 1 line Changed paths: M /PALISNC/branches/dhe_oracle_tablespaces_fuer_appcom/database/install/10.2.0/linux/config/config.sh A /PALISNC/branches/dhe_oracle_tablespaces_fuer_appcom/sources/pack/feacfgva/setup/config/af7ll197.properties Anpassung der Tablespaces f?\195?\188r AppCom Umgebung. r1947 | dheinric | 2011-05-17 07:38:35 +0200 (Tue, 17 May 2011) | 1 line Changed paths: A /PALISNC/branches/dhe_oracle_tablespaces_fuer_appcom (from /PALISNC/branches/dhe_oracle_tablespaces_f?\195?\188r_appcom:1946) D /PALISNC/branches/dhe_oracle_tablespaces_f?\195?\188r_appcom Branch umbenannt. r1946 | dheinric | 2011-05-17 07:36:55 +0200 (Tue, 17 May 2011) | 1 line Changed paths: A /PALISNC/branches/dhe_oracle_tablespaces_f?\195?\188r_appcom (from /PALISNC/tags/PALIS_3.8.4_ENT_00:1945) Branch erzeugt. [More output snipped off] As can be seen here, the branch "dhe_oracle_tablespaces_für_appcom" has been created in rev 1946, and then renamed to "dhe_oracle_tablespaces_fuer_appcom" to remove the german ü umlaut from the name. So I'd expect the base rev. of the branch to be 1946. But when I use "svn log --stop-on-copy", it stops at a different one: svn log -q --stop-on-copy https://sdmpudpagport.sdm.de/pu/dpagpalis/svn/repository/software/branches/dhe_oracle_tablespaces_fuer_appcom r1954 | hardt | 2011-05-19 13:51:17 +0200 (Do, 19. Mai 2011) This is the very first revision as shown in the previous command. Of course, if I now use this revision to find out what has changed on the branch, I won't get any output although one file has been modified and one has been changed (in rev 1950. svn client version info: % svn --version svn, version 1.6.12 (r955767) compiled Mar 22 2011, 19:47:54 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme Don't know the server version, though. Bye... Dirk -- Dirk Heinrichs | Tel: +49 (0)211 56623 316 Configuration Manager | Fax: +49 (0)211 56623 450 Capgemini Deutschland | Mail: dirk.heinri...@capgemini.com Wanheimerstraße 68 | Web: http://www.de.capgemini.com D-40468 Düsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: wwwkeys.pgp.net signature.asc Description: This is a digitally signed message part.
Re: Possible bug: --stop-on-copy stops too early
Am Dienstag, 24. Mai 2011, 12:22:44 schrieb Stephen Butler: > The "A", along with the "from :", means that /software was > copied from /PALISNC in this revision, so 'svn log --stop-on-copy' stops > at this revision. > > I searched for "--stop-on-copy" in the bug tracker, and turned up > > http://subversion.tigris.org/issues/show_bug.cgi?id=2518 > "Allow --stop-on-copy to traverse a fixed number of copies > 1" > > Unfortunately no one's picked it up yet. There's an interesting suggestion > in the comments: the log shouldn't stop if the copy-source was deleted in > the same revision. Of course, that assumes that the delete and the copy > (the two halves of the renaming) were committed in the same revision. Hmm, if it stops on _any_ copy, then maybe "svn log --stop-on-copy" is the wrong command for finding the base rev of a branch. Is there a better alternative? Bye... Dirk -- Dirk Heinrichs | Tel: +49 (0)211 56623 316 Configuration Manager | Fax: +49 (0)211 56623 450 Capgemini Deutschland | Mail: dirk.heinri...@capgemini.com Wanheimerstraße 68 | Web: http://www.de.capgemini.com D-40468 Düsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: wwwkeys.pgp.net signature.asc Description: This is a digitally signed message part.
Re: Possible bug: --stop-on-copy stops too early
Am Dienstag, 24. Mai 2011, 16:36:11 schrieb Varnau, Steve (Neoview): > > Hmm, if it stops on any copy, then maybe "svn log --stop-on-copy" is > > the wrong command for finding the base rev of a branch. Is there a > > better alternative? > > I find it is better for this use case to log from past forward to find this > info. This is my trusty command to find a branch point: > > svn log -qv -r0:HEAD -l1 --stop-on-copy Sorry, but this also doesn't work for me (gives the wrong revision as per my first mail). Bye... Dirk -- Dirk Heinrichs | Tel: +49 (0)211 56623 316 Configuration Manager | Fax: +49 (0)211 56623 450 Capgemini Deutschland | Mail: dirk.heinri...@capgemini.com Wanheimerstraße 68 | Web: http://www.de.capgemini.com D-40468 Düsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: wwwkeys.pgp.net signature.asc Description: This is a digitally signed message part.
RE: Two-Site Subversion Repository Setup Ideas
Am Montag, den 06.06.2011, 11:55 +0200 schrieb Andreas Tscharner: > > I am looking for suggestions from the community as to how > > best address the setup issue outlined below. > > > > We have two sites wanting to use Subversion that are > > performing parallel development of the same software. Due to > > security restrictions, the two sites are unable to > > communicate electronically; all data transfers must be via > > media (CD-ROM/DVD). Site A is the main site and is > > responsible for overall configuration control. > > > > Is there a way to setup the two subversion repositories to > > somehow automate keeping the two repositories in sync? We > > are usually passing media back and forth once a week, but > > currently we are doing a manual sync process that is both > > time-consuming and error-prone. > > People here will hate me for this, but I think you should switch to a > DVCS (Distributed Version Control System), like Mercurial or git. While > I don't know git, in Mercurial you have the possibility to save and > export you changes as so-called bundle at one site and import them at > the other site. For more information: > http://www.selenic.com/mercurial/hg.1.html#bundle Monotone has similar capabilities, too. And there's ClearCase(tm) with MultiSite(tm), of course (if your management is willing to spend some $$$). HTH... Dirk Firma: Capgemini Deutschland GmbH Geschaeftsfuehrer: Dr. Michael Schulte (Vorsitzender), Sven Breipohl, Burkhard Kehrbusch, Peter Laggner, Josef Ranner Amtsgericht Berlin-Charlottenburg, HRB 98814 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Re: Two-Site Subversion Repository Setup Ideas
Am Montag, den 06.06.2011, 07:52 -0500 schrieb Les Mikesell: > If you are doing this in 2 directions, won't the disconnected > repositories eventually drift out of sync as the people resolving > conflicts make different choices - regardless of how well the VCS > manages the details? I guess you're talking about conflicts in the code? This can be handled by working on branches. If each task is done in its own branch, on which only one person should work, then conflict resolution is only needed when the branch is rebased to the latest tag (which is usually done by the person responsible for the branch). Merging the branch back to trunk (--reintegrate) is then conflict-free. Bye... Dirk Firma: Capgemini Deutschland GmbH Geschaeftsfuehrer: Dr. Michael Schulte (Vorsitzender), Sven Breipohl, Burkhard Kehrbusch, Peter Laggner, Josef Ranner Amtsgericht Berlin-Charlottenburg, HRB 98814 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Re: Two-Site Subversion Repository Setup Ideas
Am Dienstag, den 07.06.2011, 08:13 -0500 schrieb Les Mikesell: > Yes, I have a hard time visualizing how any tool can help with > concurrent changes if one side doesn't stop while the merges happen > both ways and the results get back. Just look at Clearcase (again, sorry :) ). First, it has excellent merge (tracking) capabilities. People can merge between branches in BOTH directions as often as they like/need. And secondly, it prohibits working on branches which don't belong to the local replica. That means that users on other sites are forced to work on branches, which are different from the branches being worked on at the local site. If you are used to working with branches, it doesn't matter anymore from which site it comes. > Some may be better at permitting the teams to keep working while the > code diverges, but that's not necessarily a good thing. Well, it is a good thing. That's the purpose of version control systems, letting people keep working while the code diverges. Having different replicas of the same repository is just "syntactic sugar". Bye... Dirk Firma: Capgemini Deutschland GmbH Geschaeftsfuehrer: Dr. Michael Schulte (Vorsitzender), Sven Breipohl, Burkhard Kehrbusch, Peter Laggner, Josef Ranner Amtsgericht Berlin-Charlottenburg, HRB 98814 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. signature.asc Description: signature.asc
Strange merge behaviour
Hi,
I'm facing a problem where I get items modified by a merge although
there should be nothing to merge at all.
I create a new branch from trunk.
I checkout from that new branch.
I merge from trunk into the new branch.
[ No intermediate commit did happen as I'm doing this on a personal
backup copy of the repository. ]
svn status now shows some modified elements, and if I look at them with
svn diff, I get something like
Property changes on: path/to/file
___
Modified: svn:mergeinfo
Merged /project/trunk/path/to/file:r1234
Why is this and how can I get rid of this strange behaviour?
Thanks...
Dirk
--
Dirk Heinrichs | Tel: +49 (0)211 56623 316
Configuration Manager | Fax: +49 (0)211 56623 450
Capgemini Deutschland | Mail: dirk.heinri...@capgemini.com
Wanheimerstraße 68 | Web: http://www.de.capgemini.com
D-40468 Düsseldorf | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: wwwkeys.pgp.net
Firma: Capgemini Deutschland GmbH
Geschaeftsfuehrer: Dr. Michael Schulte (Vorsitzender), Sven Breipohl, Burkhard
Kehrbusch, Peter Laggner, Josef Ranner
Amtsgericht Berlin-Charlottenburg, HRB 98814
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not the
intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message
in error, please notify the sender immediately and delete all copies of this
message.
signature.asc
Description: signature.asc
Re: Strange merge behaviour
Am 09.06.2011 16:30, schrieb Sulser, Timothy (IFPRI):
I don't think you'll be able to get rid of that behavior unless you change your
strategy for making personal backups.
The personal backup was made solely to reproduce the problem in a clean
environment, without interference from other devs.
Bye...
Dirk
--
Dirk Heinrichs | Tel: +49 (0)211 56623 316
Configuration Manager | Fax: +49 (0)211 56623 450
Capgemini Deutschland | Mail: dirk.heinri...@capgemini.com
Wanheimerstraße 68 | Web: http://www.de.capgemini.com
D-40468 Düsseldorf | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: wwwkeys.pgp.net
Firma: Capgemini Deutschland GmbH
Geschaeftsfuehrer: Dr. Michael Schulte (Vorsitzender), Sven Breipohl, Burkhard
Kehrbusch, Peter Laggner, Josef Ranner
Amtsgericht Berlin-Charlottenburg, HRB 98814
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message
in error, please notify the sender immediately and delete all copies of this message.
Re: Strange merge behaviour
Am 09.06.2011 16:42, schrieb Bob Archer:
Check to see if prior to your merge that file already had merge info on it. If
it does then the merge info will be updated on that item, even if that item is
not modified by the diff.
OK, but how do I get rid of this, it's really irritating for the users.
Bye...
Dirk
--
Dirk Heinrichs | Tel: +49 (0)211 56623 316
Configuration Manager | Fax: +49 (0)211 56623 450
Capgemini Deutschland | Mail: dirk.heinri...@capgemini.com
Wanheimerstraße 68 | Web: http://www.de.capgemini.com
D-40468 Düsseldorf | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: wwwkeys.pgp.net
Firma: Capgemini Deutschland GmbH
Geschaeftsfuehrer: Dr. Michael Schulte (Vorsitzender), Sven Breipohl, Burkhard
Kehrbusch, Peter Laggner, Josef Ranner
Amtsgericht Berlin-Charlottenburg, HRB 98814
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message
in error, please notify the sender immediately and delete all copies of this message.
svn update problem
Hello, I have a problem with the "svn update" command. I tried this in the command-line: C:\ >svn.exe checkout "file:///D:/Temp/SVN-Repos" "D:\Temp2" --depth immediates A D:\Temp2\Python A D:\Temp2\Neues Textdokument.txt A D:\Temp2\example.ini A D:\Temp2\screenshot-1.jpg A D:\Temp2\Kreuzung Rastatt.png Checked out revision 21. C:\ >svn.exe update "D:\Temp2\Python" --depth immediates Updating 'D:\Temp2\Python': At revision 21 The first command worked correct, but the second one did not update the folder. Actually the folder "D:\Temp2\Python" should include the child folders now but it is still empty. My Subversion version is 1.7.5. I hope this helps to solve the problem Best regards, Dirk Fehmer
Bug Report: The "svn switch" command updates a files timestamp if the property svn:keywords is set
Hi all, I'd like to file a bug in Subversion 1.9.1 and 1.9.0, but I'm not sure if it's a deliberate behavior. The problem was not encountered in Subversion 1.7.6, which we used for a long time. I didn't find anything concerning this issue in the change log. Summary: -- The "svn switch" command updates a file's timestamp, if the property svn:keywords is set. Subversion Version: 1.9.1, 1.9.0 - svn, version 1.9.1 (r1698128) compiled Sep 1 2015, 19:50:43 on x86-microsoft-windows Operating System: Windows 7 Professional, Service Pack 1 Description: --- If a file under subversion control has the property svn:keyword set and is switched to a different location in the repository, the timestamp of the file is updated to the current time. If svn:keyword is not set, the file's timestamp is not updated. This problem was not encountered in Subversion 1.7.6 we used for a long time before. We have a problem with the new behavior, because our build-system (based on gmake) will compile more or less everything, after a tag has been created and the working copy is switched to that tag, because the file timestamps are updated. To demonstrate the behavior I've built and attached a small Windows batch file (I renamed it test.b_t), you are able to execute simply on every PC. I have attached the output test.txt as well. I've shortened the output of the dir command a little bit, so that only the file date remains. The prompt is set to ':' To use the batch file, you have to change the switch commands to your specific repository location. For simplicity, the switch command switches the file to itself. This is sufficient to demonstrate the problem. Behavior: - 1.) File foo.c is created and added to the repository. 2.) No properties have been automatically set. 3.) The files timestamp is shown by dir command 4.) After 1 minute wait the svn switch command is executed - The file date does not change, since svn:keywords is not set. 5.) After another minute the svn:keywords property is set and commited. 6.) After a wait of another minute, the switch command is executed again - the file's timestamp is changed instantly. 7.) After another minute the the svn:keywords are deleted and committed. 8.) After a final wait the switch command is executed again and the timestamp is not changed. Best Regards, Dirk -- Funkwerk Engineering GmbH Dirk Wolfram Max-Giese-Str. 22, 24116 Kiel, Germany Phone: +49 431 990 818-22 Fax:+49 431 990 818-51, email: dirk.wolf...@funkwerk-sc.com Location: Kiel, Local Court Kiel, HRB: 10441 KI Managing Director: Jens-Torsten Langhammer Disclaimer: Please be informed that the content of e-mails has just informative character. Especially e-mails with commercial or contractual content will only be binding for Funkwerk Engineering GmbH if this content is confirmed in writing by letter or fax duly undersigned by two representatives of Funkwerk Engineering GmbH. Es wird ausdrücklich darauf aufmerksam gemacht, dass die Inhalte von E-mails rein informativen Charakter haben. Sie können keine geschäftserhebliche und/oder rechtsverbindliche Wirkung entfalten. Funkwerk Engineering GmbH ist nur an den Inhalt der E-mails gebunden, wenn dieser schriftlich entweder durch Brief oder durch Fax unterschrieben von zwei Personen bestätigt wird. :echo "Test" 1>foo.c :svn add foo.c A foo.c :svn commit -m "Added foo" foo.c :svn proplist foo.c No properties for foo.c ### :dir foo.c 15.09.2015 20:21 9 foo.c # foo.c has been added to repository - and we wait 1 minute ### :sleep 61 :svn switch https://tetra.funkwerk-sc.com/test/project2/trunk/src/module2/test/foo.c foo.c :dir foo.c 15.09.2015 20:21 9 foo.c # foo.c has been switched ### :sleep 61 :svn propset svn:keywords "" foo.c property 'svn:keywords' set on 'foo.c' :svn commit -m "Added empty property svn:keyword" foo.c :svn proplist foo.c Properties on 'foo.c': svn:keywords :dir foo.c 15.09.2015 20:21 9 foo.c # foo.c now has property svn:keywords and we wait another minute ### :sleep 61 :svn switch https://tetra.funkwerk-sc.com/test/project2/trunk/src/module2/test/foo.c foo.c :dir foo.c # foo.c has a new timestamp after switch - and we wait another minute### :sleep 61 :svn propdel svn:keywords foo.c property 'svn:keywords' deleted from 'foo.c'. :svn commit -m "Removed property svn:keywords" foo.c :dir foo.c 15.09.2015 20:25 9 foo.c property svn:keywords removed - we wait 1 last minute :sleep 61 :svn switch https://tetra.funkwerk-sc.com/test/project2/trunk/src/module2/test/foo.c foo.c :dir foo.c 15.09.2015 20:25 9 foo.c No change of date after 1 Minute test.b_t Description: test.b_t
AW: Bug Report: The "svn switch" command updates a files timestamp if the property svn:keywords is set
Hi Stefan, sorry this was an accident. Of course this mail should go to users@subversion.apache.org as well. BR, Dirk -Ursprüngliche Nachricht- Von: Stefan Sperling [mailto:s...@elego.de] Gesendet: Mittwoch, 16. September 2015 13:32 An: Wolfram, Dirk Betreff: Re: Bug Report: The "svn switch" command updates a files timestamp if the property svn:keywords is set Hi Dirk, Did you drop the users list address from Cc intentionally? I'd like us to keep this discussion on the mailing list so other people can contribute to it. Thanks. On Wed, Sep 16, 2015 at 11:00:51AM +, Wolfram, Dirk wrote: > Hi Stefan, > > I agree that the use of the svn:keywords "URL" has to effect a file's > contents if $URL$ is used and therefore the timestamp has to be changed as > well. > > But even if the $URL$ keyword is not set and the file contents is not > modified during switch, a change of the timestamp occurs. > In my example I reduced this to an empty svn:keywords property. > > We are mainly using svn:keywords "Author Revision Date", so none of this > would effect the file's contents while switching. > And even if "URL" is set in the svn:keywords property but $URL$ is not used, > there is no need of updating this file. > > But I understand that it's a matter of how issue #1975 was fixed and it's of > course easier to just update all files with the svn:keywords property instead > of parsing them for $URL$ and $Header$ keywords and only modify them if > changes occur. > > Anyway I would appreciate, if either the presence of svn:keywords "URL > Header" would be evaluated or the actual occurance of $URL$ or $Header$ in > the file. > > Presently I think we have to live with the behavior and I've to decide, > whether we have to remove the keywords or live with the fact that big parts > of our system are going to be rebuild after switching. > > Best Regards, > Dirk > > -Ursprüngliche Nachricht- > Von: Stefan Sperling [mailto:s...@elego.de] > Gesendet: Mittwoch, 16. September 2015 10:42 > An: Wolfram, Dirk > Cc: users@subversion.apache.org > Betreff: Re: Bug Report: The "svn switch" command updates a files > timestamp if the property svn:keywords is set > > On Tue, Sep 15, 2015 at 06:57:43PM +, Wolfram, Dirk wrote: > > Hi all, > > > > I'd like to file a bug in Subversion 1.9.1 and 1.9.0, but I'm not sure if > > it's a deliberate behavior. > > The problem was not encountered in Subversion 1.7.6, which we used for a > > long time. > > I didn't find anything concerning this issue in the change log. > > > > Summary: > > -- > > The "svn switch" command updates a file's timestamp, if the property > > svn:keywords is set. > > I believe this is a side effect of the fix for issue #1975 "svn switch does > not update keywords" > http://subversion.tigris.org/issues/show_bug.cgi?id=1975 > > When svn updates a keyword it has to modify the file content and rewrite the > file so the time stamp gets updated. > > I would argue your expectation that a file's time stamp won't be updated by > svn switch is in direct contradiction to your use of svn:keywords on the same > file. You can't really have both.
SVN log-diff crashes if server not available
Repro = SVN checkout, make changes to a file, SVN commit, SVN log. Remove access to the SVN server (mine is accessible only via VPN, so disconnect VPN). Right-click a file, SVN Show Log, press Offline for now (not the default), find the file modification in the path/action list. Then either double-click on the file, or right-click on the file : Show Changes. The result is as follows: Subversion Exception! Subversion encountered a serious problem. ... In file 'D:\Development\SVN\Releases\TortoiseSVN-1.11.0\ext\subversion\subversion\libsvn_wc\wc_db.c' line 10238: assertion failed (svn_dirent_is_absolute(local_abspath)) Pressing OK results in another pop-up: TortoiseSVN Subversion reported an error: 'C:\Users\\AppData\Local\Temp\3' is not a working copy (My sandbox is in C:\_SVN, not C:\Users. Maybe Windows is virtualizing storage for SVN? Maybe a check for server accessibility isn't quite right?) The workaround is to reconnect to the server (reconnect the VPN in my case), but I was surprised that SVN would crash when offline. Thanks in advance for your attention. -Dirk
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
