Subversion log format in Japanese
Hello, I have a question regarding the format of the date displayed in the log of a repository when using a Japanese locale. Specifically, the format of the "human timestamp format suffix" (as it is described in libsvn_subr/time.c) doesn't seem to be quite right and I'm wondering if there is a reason for the format as it is. For example, if you were to execute $ svn log http://svn.apache.org/repos/asf/subversion in English you would see date lines such as "r1302758 | hwright | 2012-03-20 11:34:26 +0900 (Tue, 20 Mar 2012) | 14 lines" The "(Tue, 20 Mar 2012)" part is dictated by the "human timestamp format suffix" in libsvn_subr/time.c and in Japanese if you execute the same command you get, "r1302758 | hwright | 2012-03-20 11:34:26 +0900 (火, 20 3月 2012) | 14 lines" This doesn't seem to be right because the order is the exact opposite of what one would expect (normally this would be ordered as year, month, day, day of week) and only the month has the character for month (whereas the day and year do not have the characters for day and year so there is a lack of consistency). In other words, I would expect that in Japanese I would get something like, "r1302758 | hwright | 2012-03-20 11:34:26 +0900 (2012年3月20日 (火)) | 14 lines" I have adjusted this on my system by changing the msgstr for msgid " (%a, %d %b %Y)" from " (%a, %d %b %Y)" to " (%x (%a))". This feels like a bug to me and I looked at the latest version of the Japanese po file (revision 1302772, line 6238) and I see that the format is still " (%a, %d %b %Y)". I have googled around a bit and looked in through the issue list, etc, and I haven't found any discussion on this and I'm wondering if there is a particular reason for this format or is it just that nobody has said anything yet or...? Berin
Re: Subversion log format in Japanese
On Tue, Mar 20, 2012 at 04:24:11PM +0900, Berin Babcock-McConnell wrote: > Hello, > > I have a question regarding the format of the date displayed in the > log of a repository when using a Japanese locale. Specifically, the > format of the "human timestamp format suffix" (as it is described in > libsvn_subr/time.c) doesn't seem to be quite right and I'm wondering > if there is a reason for the format as it is. > > For example, if you were to execute > > $ svn log http://svn.apache.org/repos/asf/subversion > > in English you would see date lines such as > > "r1302758 | hwright | 2012-03-20 11:34:26 +0900 (Tue, 20 Mar 2012) | > 14 lines" > > The "(Tue, 20 Mar 2012)" part is dictated by the "human timestamp > format suffix" in libsvn_subr/time.c and in Japanese if you execute > the same command you get, > > "r1302758 | hwright | 2012-03-20 11:34:26 +0900 (火, 20 3月 2012) | > 14 lines" > > This doesn't seem to be right because the order is the exact > opposite of what one would expect (normally this would be ordered as > year, month, day, day of week) and only the month has the character > for month (whereas the day and year do not have the characters for > day and year so there is a lack of consistency). > > In other words, I would expect that in Japanese I would get something like, > > "r1302758 | hwright | 2012-03-20 11:34:26 +0900 (2012年3月20日 (火)) > | 14 lines" > > I have adjusted this on my system by changing the msgstr for msgid " > (%a, %d %b %Y)" from " (%a, %d %b %Y)" to " (%x (%a))". > > This feels like a bug to me and I looked at the latest version of > the Japanese po file (revision 1302772, line 6238) and I see that > the format is still " (%a, %d %b %Y)". I have googled around a bit > and looked in through the issue list, etc, and I haven't found any > discussion on this and I'm wondering if there is a particular reason > for this format or is it just that nobody has said anything yet > or...? Did you see this part of the comment above the human-readable date format string? * [..] The * human explanatory part is generated by apr_strftime, which means * that its generation can be affected by locale, it can fail and it * doesn't need to be constant in size. In other words, perfect to be * converted to a configuration option later on. IOW, there are many strftime() format flags people might want to use. The correct date format can be based on the locale. But it might just as well be based on personal preferences. So the strftime() format string for the human-readable part of the date is hardcoded in the code right now and it is unfortunate that this looks bad in some locales. Is there an alternative strftime() format string that would produce the desired result in English, Japanese and any other language? If so, we could use that instead. Or we could add a new feature to make the format string configurable. As the comment suggests, there could be a client-side configuration option that allows users to specify an strftime() compatible format string that Subversion should use here, with the current format string as default. Would you like to submit a patch that implements either of these approaches?
RE: preventing commits (this is *not* a classic hook question)
> Hello, > > I'm wondering if there is any strategy for temporary preventing people from > committing to a svn repository, without the person who sets the hook (or sth > similar) being the admin of the svn repository. Thus, in this case, there is > no > option to directly access the /hooks/ folder. Create a project in your repository that contains a config file of some type. Give write access to this path only to those people that you want to be able to enable/disable checkins. Create a working copy of said config project and check it out on your svn server. Have your hook script update the working copy (or perhaps have a cron job that updates this wc every 60 seconds or whatever) and read this config file to determine if commits are allowed. All the users will have to do is edit the config file and commit it. BOb > > A "poor man's" option could be working with locks. But, recursively locking a > large repo path could be inefficient, and locks can be stolen anyway. So it > looks > like the wrong approach from many perspectives. > > Any idea for preventing commits, for a specific time, without being able to > directly accessing the hooks folder? > If the access is through svn+ssh and you can be granted access to the > authorized_keys, you can tweak it to read-only. If it's an Apache based access > with HTTPS, you can manipulate the Apache config (which requires reloading > the Apache server configuration, or control of a .htaccess file) > > Means vary depending on which technology you use and what you *do* have > access to.
Call svn cat for all files modified or added in a given revision
Hello all, Using svn cat I can see the state of a file at a given revision. As it turns out, I have had in the past some files that were commit with inconsistent line endings and that are making analysis tools stop because of this. What I want to do is find which (file, revision) pairs are impacted so that I can go back in the past and fix those invalid commits (using dump/reload). However, I'm having a hard time finding a way to extract a list of modified or added files in a given revision so that I could give that list to the svn cat command that stops with an error when the above situation arises. And then, once this works, I'd put all this in a loop going from the first revision to the last one. I don't mind if this takes time, and I have no preference as to what operating system this should run under between Linux and Windows I believe using Linux would be much simpler, but still, I can't figure out how to parse the result of svn log -v so that I can extract the filenames to give to svn cat. If need be, I can work out of a working copy. I would very much appreciate any help on this matter Regards Olivier
Re: Subversion log format in Japanese
(2012年03月20日 21:04), Stefan Sperling wrote: On Tue, Mar 20, 2012 at 04:24:11PM +0900, Berin Babcock-McConnell wrote: Hello, I have a question regarding the format of the date displayed in the log of a repository when using a Japanese locale. Specifically, the format of the "human timestamp format suffix" (as it is described in libsvn_subr/time.c) doesn't seem to be quite right and I'm wondering if there is a reason for the format as it is. For example, if you were to execute $ svn log http://svn.apache.org/repos/asf/subversion in English you would see date lines such as "r1302758 | hwright | 2012-03-20 11:34:26 +0900 (Tue, 20 Mar 2012) | 14 lines" The "(Tue, 20 Mar 2012)" part is dictated by the "human timestamp format suffix" in libsvn_subr/time.c and in Japanese if you execute the same command you get, "r1302758 | hwright | 2012-03-20 11:34:26 +0900 (火, 20 3月 2012) | 14 lines" This doesn't seem to be right because the order is the exact opposite of what one would expect (normally this would be ordered as year, month, day, day of week) and only the month has the character for month (whereas the day and year do not have the characters for day and year so there is a lack of consistency). In other words, I would expect that in Japanese I would get something like, "r1302758 | hwright | 2012-03-20 11:34:26 +0900 (2012年3月20日 (火)) | 14 lines" I have adjusted this on my system by changing the msgstr for msgid " (%a, %d %b %Y)" from " (%a, %d %b %Y)" to " (%x (%a))". This feels like a bug to me and I looked at the latest version of the Japanese po file (revision 1302772, line 6238) and I see that the format is still " (%a, %d %b %Y)". I have googled around a bit and looked in through the issue list, etc, and I haven't found any discussion on this and I'm wondering if there is a particular reason for this format or is it just that nobody has said anything yet or...? Did you see this part of the comment above the human-readable date format string? * [..] The * human explanatory part is generated by apr_strftime, which means * that its generation can be affected by locale, it can fail and it * doesn't need to be constant in size. In other words, perfect to be * converted to a configuration option later on. IOW, there are many strftime() format flags people might want to use. The correct date format can be based on the locale. But it might just as well be based on personal preferences. So the strftime() format string for the human-readable part of the date is hardcoded in the code right now and it is unfortunate that this looks bad in some locales. Is there an alternative strftime() format string that would produce the desired result in English, Japanese and any other language? If so, we could use that instead. Or we could add a new feature to make the format string configurable. As the comment suggests, there could be a client-side configuration option that allows users to specify an strftime() compatible format string that Subversion should use here, with the current format string as default. Would you like to submit a patch that implements either of these approaches? Yes, I did notice that comment. I also noticed the following comment in the po file, TRANSLATION-FIXME: If APR supported reordering of format indicators Human explanatory part, generated by apr_strftime as "Sat, 01 Jan 2000" To be honest neither made much sense to me because my understanding is that the locale dependent string is getting printed out. In other words, Subversion takes human_timestamp_format_suffix and asks for the format string that is appropriate for the current locale. If there were an alternate strftime() format string that produces the correct result in all languages that would be great. But it seems that there is not and that is why there is a localization string in the po file, right? I can see why it might be nice to give people a slightly more flexible method for overriding the format string than updating their local mo file and in googling this I got the feeling some client (maybe Turtoise?) allows you to do this with properties (although I'm not sure since I didn't pursue this)... But I'm suggesting that the current string for human_timestamp_format_suffix in the ja.po file isn't the best. I've noticed that many other languages have human_timestamp_format_suffix strings that differ from the default and I'm wondering why this is not the case with Japanese?
Re: Call svn cat for all files modified or added in a given revision
On Tue, Mar 20, 2012 at 10:39, OBones wrote: > Hello all, > > Using svn cat I can see the state of a file at a given revision. > As it turns out, I have had in the past some files that were commit with > inconsistent line endings and that are making analysis tools stop because of > this. Can you change analysis tools to one that can handle this condition? > What I want to do is find which (file, revision) pairs are impacted so that > I can go back in the past and fix those invalid commits (using dump/reload). > > However, I'm having a hard time finding a way to extract a list of modified > or added files in a given revision so that I could give that list to the svn > cat command that stops with an error when the above situation arises. > And then, once this works, I'd put all this in a loop going from the first > revision to the last one. svn log --verbose -rX will give you a list of all paths touched in revision X. You'll need to do some parsing to extract just the paths vs. the other log data. If you're handy with XML, you can use svn log --verbose --xml -rX and then use XPath to extract just the paths. To parse the output of svn log --verbose for this project, look for any line starting with one or more letters and/or spaces, followed by a space, followed by a slash. From that space to the end of the line is the path that was touched. The regex should be something close to this: \b[\w\s]+(\/*)\b
possible switch bug in conjunction with file-externals
attached is my shell-script "svn-bug.sh" to reproduce the error. also attached is the logfile from "bash -x ./svn-bug.sh > svn-bug.out 2>&1" short description: I replaced some files in some branches with file-externals. when switching between these different branches (with real files and with file-externals) the files get lost. even worse: when being in that state, svn doesn't tell me that something is wrong ok, I once get an error message from the switch command, but since my project trees are very large, the error message gets scrolled out. questions: * did I miss some important informations? * is this a bug, or did I do something wrong or misunderstood something? * is the bug already in the issue tracker? * do I report the bug to the issue tracker or does one of you gurus report the issue? regards, Schludi Wolfgang Schludi Dipl.-Inf. (FH) ___ stb ag Stettenstrasse 6 D-86150 Augsburg Phone: +49 (0) 821 319876-29 Mobile: Fax: +49 (0) 821 319876-80 E-mail: wolfgang.schl...@stb-ag.com Internet: http://www.stb-ag.com Vertretungsberechtigter VorstandDr. Stefan Berchtold, Markus H?vermann Registergericht Amtsgericht Augsburg Registernummer HRB 2083 Umsatzsteuer-Identifikationsnummer gem?? ? 27 a Umsatzsteuergesetz DE 199 299 766 Aufsichtsratsvorsitzender Alexander Schmitz-Elsen svn-bug.sh Description: svn-bug.sh svn-bug.out Description: svn-bug.out
Re: Subversion log format in Japanese
On Tue, Mar 20, 2012 at 11:46:58PM +0900, Berin Babcock-McConnell wrote: > If there were an alternate strftime() format string that produces > the correct result in all languages that would be great. But it > seems that there is not and that is why there is a localization > string in the po file, right? There is this comment in fr.po: # Hmmm... what about "%x" (preferred date representation in locale) # instead? > I can see why it might be nice to give people a slightly more > flexible method for overriding the format string than updating their > local mo file and in googling this I got the feeling some client > (maybe Turtoise?) allows you to do this with properties (although > I'm not sure since I didn't pursue this)... > > But I'm suggesting that the current string for > human_timestamp_format_suffix in the ja.po file isn't the best. > > I've noticed that many other languages have > human_timestamp_format_suffix strings that differ from the default > and I'm wondering why this is not the case with Japanese? I don't really know either. This subject is new to me, too. You're right that there is precedent for changing the format string in localised text and also re-arrange the format specifiers (ko.po, pl.po, and zh_CN.po). So as a first step, we could fix the format string in ja.po as you suggest. Do you want to send a patch for that? See http://subversion.apache.org/docs/community-guide/general.html#patches and http://subversion.apache.org/docs/community-guide/l10n.html for background information about translations. We could also investigate if %x is acceptable and works as expected everywhere. Choose whichever path forward you prefer :)
Re: preventing commits (this is *not* a classic hook question)
Bob Archer wrote: >> Hello, >> >> I'm wondering if there is any strategy for temporary preventing people from >> committing to a svn repository, without the person who sets the hook (or sth >> similar) being the admin of the svn repository. Thus, in this case, there is >> no >> option to directly access the /hooks/ folder. > >Create a project in your repository that contains a config file of some type. >Give write access to this path only to those people that you want to be able to >enable/disable checkins. > >Create a working copy of said config project and check it out on your svn >server. >Have your hook script update the working copy (or perhaps have a cron job that >updates this wc every 60 seconds or whatever) and read this config file to >determine if commits are allowed. > >All the users will have to do is edit the config file and commit it. slight modification to that solution: Create a revprop in revision 0 in your repository that contains a the block/noblock information Give write access to this revprop only to those people that you want to be able to enable/disable checkins. Have your hook script check this revprop to determine if commits are allowed. All the users will have to do is edit the revprop (no commit required). Original version has the side benefit of providing an audit trail for the configuration changes. -- Lorenz
Re: predecessor count for the root node-revision is wrong message
Daniel Shahaf wrote on Tue, Mar 20, 2012 at 00:49:06 +0200: > The time until 1.7.5 is counted in weeks, and 1.6.18 is scheduled to be > released next week. > The fix was merged to 1.6.x@HEAD today and barring surprises will be included in 1.6.18.
Re: SVN externals (externals failed, already locked)
On 13/03/12 18:07, Matthew J Fletcher wrote: Hi, I've been expermenting with SVN externals and found an issue which i dont fully understand. My repository is as follows; -- +Play (with and extern to URL "https://swserver:8443/svn/Play/Shared Sources" Local Path "Project 3") - Project 3 (externed) -> shared.txt - Project 2 (with an extern to URL "https://swserver:8443/svn/Play/Shared Sources" Local Path "Outstation Files") -> -> Outstation Files (externed) -> -> -> shared.txt -> -> unieque.txt -> Project 1 (with an extern to URL "https://swserver:8443/svn/Play/Shared Sources" Local Path "osfiles") -> -> osfiles (externed) -> -> -> shared.txt -> -> unieque.txt - Shared Sources -> shared.txt - All the externs work as expected and changes to files in "Shared Sources" are reflected across the 3 projects. However when doing an update/checkout i get the following error " 'External failed Project 3' is allready locked via ." I suspect that its because i am external'ing not into a seperate folder, whereas in "Project 1" and "Project 2" the "Shared Sources" go in there own folder. However the externals do work as expected. I am using subversion 1.7.4 (same on server), via TortoiseSVN. Hi, Has anyone tried to do this before and encountered this problem ? or can offer some advice on this usage of externs. regards - Matthew J Fletcher
RE: preventing commits (this is *not* a classic hook question)
Hello Bob, Nico, Les, thanks for your pointers. Great help, exactly what I've looked for. Thanks!! Michael >> Hello, >> >> I'm wondering if there is any strategy for temporary preventing people >> from >> committing to a svn repository, without the person who sets the hook (or >> sth >> similar) being the admin of the svn repository. Thus, in this case, >> there is no >> option to directly access the /hooks/ folder. > > Create a project in your repository that contains a config file of some > type. Give write access to this path only to those people that you want to > be able to enable/disable checkins. > > Create a working copy of said config project and check it out on your svn > server. Have your hook script update the working copy (or perhaps have a > cron job that updates this wc every 60 seconds or whatever) and read this > config file to determine if commits are allowed. > > All the users will have to do is edit the config file and commit it. > > BOb > > >> >> A "poor man's" option could be working with locks. But, recursively >> locking a >> large repo path could be inefficient, and locks can be stolen anyway. So >> it looks >> like the wrong approach from many perspectives. >> >> Any idea for preventing commits, for a specific time, without being able >> to >> directly accessing the hooks folder? >> If the access is through svn+ssh and you can be granted access to the >> authorized_keys, you can tweak it to read-only. If it's an Apache based >> access >> with HTTPS, you can manipulate the Apache config (which requires >> reloading >> the Apache server configuration, or control of a .htaccess file) >> >> Means vary depending on which technology you use and what you *do* have >> access to. > >
Re: SVN externals (externals failed, already locked)
Matthew J Fletcher writes: > I've been expermenting with SVN externals and found an issue which i > dont fully understand. My repository is as follows; > > > -- > > +Play (with and extern to URL "https://swserver:8443/svn/Play/Shared > Sources" Local Path "Project 3") > > - Project 3 (externed) > -> shared.txt > > - Project 2 (with an extern to URL > "https://swserver:8443/svn/Play/Shared Sources" Local Path "Outstation > Files") > -> -> Outstation Files (externed) > -> -> -> shared.txt > -> -> unieque.txt > > -> Project 1 (with an extern to URL > "https://swserver:8443/svn/Play/Shared Sources" Local Path "osfiles") > -> -> osfiles (externed) > -> -> -> shared.txt > -> -> unieque.txt > > - Shared Sources > -> shared.txt I'm having difficulty making sense of that description. svnadmin create repo svn co file://`pwd`/repo wc svn mkdir wc/Play svn mkdir wc/Play/SharedSources echo foo > wc/Play/SharedSources/shared.txt svn add wc/Play/SharedSources/shared.txt svn mkdir wc/Play/Project1 svn mkdir wc/Play/Project2 svn ps svn:externals '^/Play/SharedSources Outstation' wc/Play/Project1 svn ps svn:externals '^/Play/SharedSources osfiles' wc/Play/Project2 svn ps svn:externals '^/Play/SharedSources Project3' wc/Play # or maybe one svn:externals on Play # ^/Play/SharedSources Project3 # ^/Play/SharedSources Project2/Outstation # ^/Play/SharedSources Project1/osfiles svn ci -mm wc svn up wc echo mod >> wc/Play/SharedSources/shared.txt svn ci -mm wc svn up wc > All the externs work as expected and changes to files in "Shared > Sources" are reflected across the 3 projects. However when doing an > update/checkout i get the following error " 'External failed Project > 3' is allready locked via ." I don't understand that either. How can the externs "work as expected" if neither checkout nor update work? > I suspect that its because i am external'ing not into a seperate > folder, whereas in "Project 1" and "Project 2" the "Shared Sources" go > in there own folder. However the externals do work as expected. -- Philip
random sort of svn status and svn diff
Hi, I am facing a problem I do a svn diff | lsdiff I got file in random order , also happens with svn status How I sort diff and status , or at least don't get random results I am using subversion-1.6.17-5.fc16.x86_64 on Fedora 17 I had clean my $HOME/.subversion nothing change, happens with at least 2 repos ( all that I tested ) Example: #svn diff | lsdiff rsst2.config stop_prod.sh test.sh start_prod.sh local.defs rsst.defs #svn diff | lsdiff local.defs rsst.defs rsst2.config stop_prod.sh test.sh start_prod.sh #svn diff | lsdiff test.sh start_prod.sh local.defs rsst.defs rsst2.config stop_prod.sh Thanks, -- Sérgio M. B.
Re: random sort of svn status and svn diff
On Mar 20, 2012, at 19:17, Sérgio Basto wrote: > Hi, I am facing a problem > I do a svn diff | lsdiff > I got file in random order , also happens with svn status Correct, Subversion does not output these in a sorted order. > How I sort diff and status , or at least don't get random results You can pipe the result to the "sort" program somehow.
Re: random sort of svn status and svn diff
On Tue, 2012-03-20 at 19:23 -0500, Ryan Schmidt wrote: > On Mar 20, 2012, at 19:17, Sérgio Basto wrote: > > > Hi, I am facing a problem > > I do a svn diff | lsdiff > > I got file in random order , also happens with svn status > > Correct, Subversion does not output these in a sorted order. but one month ago , svn diff have always same output , now it is random , is a bug or regression. why the output shouldn't be sorted by name or something else ? or why svn don't have a sort option this is insane . I use patchutils to edit diffs more than 4 years and now with random order, mess up all results . I not say that output have one order is seems random , I'm saying every time I do a svn diff or status the order of files change OMG. > > How I sort diff and status , or at least don't get random results > > You can pipe the result to the "sort" program somehow. > > > -- Sérgio M. B.
Re: random sort of svn status and svn diff
Sérgio Basto writes: > On Tue, 2012-03-20 at 19:23 -0500, Ryan Schmidt wrote: >> On Mar 20, 2012, at 19:17, Sérgio Basto wrote: >> >> > Hi, I am facing a problem >> > I do a svn diff | lsdiff >> > I got file in random order , also happens with svn status >> >> Correct, Subversion does not output these in a sorted order. > > but one month ago , svn diff have always same output , now it is > random , is a bug or regression. That's the result of a change in the APR hash table implementation. Subversion often uses "hash order" and in the past this was always the same for a given set of hash keys. The new APR implementation means that this order is no longer constant. > why the output shouldn't be sorted by name or something else ? > or why svn don't have a sort option this is insane . It could be done but nobody has done it yet, the APR change is only a few weeks old. Sorting may need to be optional as there is a cost to sorting that not everybody would want. -- Philip
Re: preventing commits (this is *not* a classic hook question)
I have a pre-commit hook that stores its configuration inside your repository. You'll need access to the Subversion server to set it up, but once it's setup, you can control access by checking out the control file from the repository, making your changes, and then checking it back in. This is a modification of a hook that I've been using for years. Originally, the control file was kept on the server -- usually inside the hooks directory. However, that meant logging onto the server, and that was getting too difficult to do all the time. Besides, this way, I can track who changed the control file and why. What prevents anyone from changing the control file? The control file is configured, so only the administrators can modify it. You can take a look at it at https://github.com/qazwart/SVN-Precommit-Kitchen-Sink-Hook. (Yes, a Subversion hook is stored in GitHub). If you need any further help, contact me at da...@weintraub.name, and I'll see what I can do. -- David Weintraub qazw...@gmail.com
Re: random sort of svn status and svn diff
On Wed, 2012-03-21 at 00:51 +, Philip Martin wrote: > Sérgio Basto writes: > > > On Tue, 2012-03-20 at 19:23 -0500, Ryan Schmidt wrote: > >> On Mar 20, 2012, at 19:17, Sérgio Basto wrote: > >> > >> > Hi, I am facing a problem > >> > I do a svn diff | lsdiff > >> > I got file in random order , also happens with svn status > >> > >> Correct, Subversion does not output these in a sorted order. > > > > but one month ago , svn diff have always same output , now it is > > random , is a bug or regression. > > That's the result of a change in the APR hash table implementation. > Subversion often uses "hash order" and in the past this was always the > same for a given set of hash keys. The new APR implementation means > that this order is no longer constant. > > > why the output shouldn't be sorted by name or something else ? > > or why svn don't have a sort option this is insane . > > It could be done but nobody has done it yet, the APR change is only a > few weeks old. Sorting may need to be optional as there is a cost to > sorting that not everybody would want. I am a volunteer to change code to do a constant sort on svn diff and status and test it , I think that is more quick that do an external function to do that for me . I don't know any ideas for have a constant of this outputs ? Thanks, -- Sérgio M. B.
checksum assert fail
So, I did something dumb in subversion and got a nice error message telling me to tell you what I did so that in case someone else is as goofy as I, the program won't crash next time. So here I am! What I did was, on Windows 7 using Tortoise SVN, created some new files and slated them for addition with 'svn add'. But then I never committed them, and went off and did other things. Later, on a different computer, I realized I hadn't actually committed those files yet, and since I had a copy of them, I went ahead and added them, then committed the change. Later still, back on my Windows machine, I wanted to do an svn update. But the little blue 'plus' from tortoise was looking at me, forlorn, and I thought, "Self, I don't want my pending add to mess up my svn update! I better delete those files first." So I did. And then I ran SVN update, and it failed horribly and I said to myself, "oops." I've since tried to run 'cleanup' and things are still broken, and I'm getting the following message, which is pretty similar (if not exactly the same) as the one I got originally: --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.7.1\ext\subversion\subversion\libsvn_wc\workqueue.c' line 672: assertion failed (checksum != NULL) --- OK --- If there's something I can do about this besides re-checking out this directory, that'd be great, but if not, ah, well. -Lucian
Re: SVN externals (externals failed, already locked)
On 20/03/12 23:58, Philip Martin wrote: Matthew J Fletcher writes: I've been expermenting with SVN externals and found an issue which i dont fully understand. My repository is as follows; -- +Play (with and extern to URL "https://swserver:8443/svn/Play/Shared Sources" Local Path "Project 3") - Project 3 (externed) -> shared.txt - Project 2 (with an extern to URL "https://swserver:8443/svn/Play/Shared Sources" Local Path "Outstation Files") -> -> Outstation Files (externed) -> -> -> shared.txt -> -> unieque.txt -> Project 1 (with an extern to URL "https://swserver:8443/svn/Play/Shared Sources" Local Path "osfiles") -> -> osfiles (externed) -> -> -> shared.txt -> -> unieque.txt - Shared Sources -> shared.txt I'm having difficulty making sense of that description. svnadmin create repo svn co file://`pwd`/repo wc svn mkdir wc/Play svn mkdir wc/Play/SharedSources echo foo> wc/Play/SharedSources/shared.txt svn add wc/Play/SharedSources/shared.txt svn mkdir wc/Play/Project1 svn mkdir wc/Play/Project2 svn ps svn:externals '^/Play/SharedSources Outstation' wc/Play/Project1 svn ps svn:externals '^/Play/SharedSources osfiles' wc/Play/Project2 svn ps svn:externals '^/Play/SharedSources Project3' wc/Play # or maybe one svn:externals on Play # ^/Play/SharedSources Project3 # ^/Play/SharedSources Project2/Outstation # ^/Play/SharedSources Project1/osfiles svn ci -mm wc svn up wc echo mod>> wc/Play/SharedSources/shared.txt svn ci -mm wc svn up wc I am not sure how that corresponds to what i created via TortoiseSVN, i will use the commandline when i have access to the repository again and post the results. All the externs work as expected and changes to files in "Shared Sources" are reflected across the 3 projects. However when doing an update/checkout i get the following error " 'External failed Project 3' is allready locked via ." I don't understand that either. How can the externs "work as expected" if neither checkout nor update work? I suspect that its because i am external'ing not into a seperate folder, whereas in "Project 1" and "Project 2" the "Shared Sources" go in there own folder. However the externals do work as expected. Maybe completes with errors would be a better description, see log of update command. Extern file is updated into all 3 externed places, but the extern for "project 3" gives an error. - Updating: C:\Users\mfletcher\Desktop\Play22 Updated: C:\Users\mfletcher\Desktop\Play22\Project 3\shared 1.txt Updated: C:\Users\mfletcher\Desktop\Play22\Shared Sources\shared 1.txt External: C:\Users\mfletcher\Desktop\Play22\Project 1\osfiles Updating: C:\Users\mfletcher\Desktop\Play22\Project 1\osfiles Updated: C:\Users\mfletcher\Desktop\Play22\Project 1\osfiles\shared 1.txt Completed: C:\Users\mfletcher\Desktop\Play22\Project 1\osfiles - at revision: 71 External: C:\Users\mfletcher\Desktop\Play22\Project 2\Outstation Files Updating: C:\Users\mfletcher\Desktop\Play22\Project 2\Outstation Files Updated: C:\Users\mfletcher\Desktop\Play22\Project 2\Outstation Files\shared 1.txt Completed: C:\Users\mfletcher\Desktop\Play22\Project 2\Outstation Files - at revision: 71 External: C:\Users\mfletcher\Desktop\Play22\Project 3 External failed: C:\Users\mfletcher\Desktop\Play22\Project 3 Error: 'C:\Users\mfletcher\Desktop\Play22\Project 3' is already locked via Error: 'C:\Users\mfletcher\Desktop\Play22'. Completed: C:\Users\mfletcher\Desktop\Play22\Project 3 - at revision: 71 Thanks for taking a look at this. --- Matthew J Fletcher amimjf(at)sky.com www.amimjf.org ---
