assertion failed (status != svn_wc__db_status_normal)
Hi. I have this error today - first one I've ever seen with SVN! I was simply running update on a repo I checked out a while back (less than 2 months), it's not had too many updates applied to it since then, so it's not a massively used repo. I'm running the latest TortoiseSVN (1.8.1) so I assume I have the latest svn too as Stefan is quite good at keeping it updated. TortoiseSVN 1.8.1, Build 24570 - 32 Bit , 2013/07/22 18:28:29 Subversion 1.8.1, -release apr 1.4.8 apr-util 1.5.2 serf 1.3.0 OpenSSL 1.0.1e 11 Feb 2013 zlib 1.2.8 I still have the wc.db but I'm not sure I can send it to you. I'm more than happy to run sql commands against it if you want to let me know what you'd be interested in. thanks Andy --- 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.8.1\ext\subversion\subversion \libsvn_wc\update_editor.c' line 3042: assertion failed (status != svn_wc__db_status_normal) --- OK This email and any attachment to it are confidential. Unless you are the intended recipient, you may not use, copy or disclose either the message or any information contained in the message. If you are not the intended recipient, you should delete this email and notify the sender immediately. Any views or opinions expressed in this email are those of the sender only, unless otherwise stated. All copyright in any Capita material in this email is reserved. All emails, incoming and outgoing, may be recorded by Capita and monitored for legitimate business purposes. Capita exclude all liability for any loss or damage arising or resulting from the receipt, use or transmission of this email to the fullest extent permitted by law.
RE: Subversion Session.
The one thing I can think of that is a must tell is the sparse checkout feature - none of the DVCSs have this, and it's a pretty damn useful part of the whole. There's the OSS training from Polarion: http://www.polarion.com/products/svn/subtrain.php SubTrain is licensed under the Creative Commons Attribution License so you are free to use it and adapt it to your needs. For more information, see Using SubTrain. You could base your session on that, and contribute back to it. -Original Message- From: Gavin Baumanis [mailto:gav...@thespidernet.com] Sent: 10 August 2011 12:42 To: dev@subversion.apache.org Development Subject: Subversion Session. Hi there, I have been invited to provide a session for an upcoming ColdFusion conference in Melbourne, Australia. Since I am the current Patch Manager and advocate of using Subversion for version control - I thought I would suggest a session about using Subversion. I envisage the session having the usual intro of what is source control and why you should use it. How Subversion came to be (to fix the short-comings of CVS) and where you can get it. For the body of the session I thought I would treat it like an O'reilly cookbook of how to do tasks with SVN. Quick points of; * Traditional directory structure * Repository version numbering * Check-In * Check-Out * Committing * SVN Keywords * Setting SVN Keywords on ALL files. * Architectural Changes of SVN 1.7 But the majority of the session would be use-cases of merging. From my own experience I found merging to be the most difficult to learn and retain, so I am sure it's a usage of SVN that others have had similar issues with. * Cherry-picking * Re-integrate * Reverse merging * Using svn merge to simulate a svn update --dry-run (svn merge --dry-run -r BASE:HEAD .) * Resolving Conflicts * Resolving Tree Conflicts (svn resolve --accept working PATH/FILES / svn resolve --accept theirs-full PATH/FILES) My reason for posting here, is; Have I missed anything that you would consider to be a must-have in a discussion of SVN? Are there any papers available about SVN that I might be able to use for research of my session and / or dissemination? Any relevant threads that people can think of? (http://svn.haxx.se/users/archive-2011-04/0209.shtml) (I will of course provide appropriate credit / references.) Additionally, is there any admin I need to observe when promoting SVN? Does it matter, at all, that I have a role in the project? As always - Thanks. Gavin.
Offline Commits (WAS: It's time to fix Subversion Merge)
-Original Message- From: Andy Singleton [mailto:a...@assembla.com] Sent: 11 July 2011 21:55 To: Bob Archer Cc: dev@subversion.apache.org Subject: Re: It's time to fix Subversion Merge If you want offline commit and private repositories, you can use git or mercurial. We use both of them at Assembla. Subversion with those features would not add much because it would look like a variant of mercurial. It would lose one big advantage of subversion, which is simplicity for the user. It would load the client up with new commands and mental models to move changes between the client repository and the server repository, and maintain local repositories. You can still have simplicity while adding offline commits. With the new WC db, it's conceivable that a --local option could be added to svn commit that would not send the changeset to the server, but would store it in the WC, temporarily. When the user then performed a normal commit, the client could replay each local commit to the server in turn. The user gets the ability to commit when not connected to the network, can also commit code they might want to revert later, the overall subversion system doesn't get changed very much at all, and the server remains unchanged. If there are updates pending, the operation performs as it does today, alerting the user to merge if necessary, but otherwise treating all the local commits as if they were just in-progress modifications. For viewing history, the client needs to show the local revisions, suitably marked. If the user has committed several changes to a file, another commit option could be added that discards all but the last change. Tools such as Tortoise could 'automatically' switch to offline working if it failed to detect a network connection. Svn wouldn't get the full features of a DVCS like offline history, but then we don't want to store a local copy of the entire repository! (that said, it would be complicated, but possible, to download a cache of the last x revisions once the WC gets the ability to store local commits to provide local diffs - though I'm not sure that would be enough of an advantage to warrant the cost of implementing).
RE: Does fsfs revprop packing no longer allow usage of traditional backup software?
-Original Message- From: Peter Samuelson [mailto:pe...@p12n.org] Sent: 30 June 2011 23:58 To: dev@subversion.apache.org Subject: Re: Does fsfs revprop packing no longer allow usage of traditional backup software? [Hyrum K Wright] I like this idea, but it would seem to introduce an additional stat() call* for every attempt to fetch a revprop, because you'd first have to check the old location, and then the packed one. Technically not an extra stat(), but an extra open(). Not the same. Especially since the common case, as you put it, is that the open() returns ENOENT, file not found. _That_ case may or may not be expensive, but it's quite different from the usual consideration of whether stat() is expensive. Not least because stat() is usually considered in context where a file _does_ exist and various information about the file gets looked up to populate the stat structure. Ok, but a) why can't the list of unpacked revprop files be cached at startup and updated as revprops are edited. If this is too much trouble, b) why not write a list of edited revprop files to a single file instead - this option may not help that much, but would at least keep the 'index' file in the OS fs cache and would prevent checking the disk for lots of revprops when returning log history and the like (ie the system would only need to read those files that you know are there, removing the need for stat calls) Or of course c) store the list of edited, unpacked revprops in a sqlite DB table. When svnsadmin pack is run, the cache, file, or table would just be wiped so there's little maintenance required - you will need to rename or delete the unpacked shards as the pack operation runs, or prevent read and writes to revprops during this operation. Andy
RE: Static code analysis (cppcheck)
-Original Message- From: Philip Martin [mailto:philip.mar...@wandisco.com] Sent: 29 June 2011 17:39 To: Julian Foad Cc: Philipp Kloke; Hyrum K Wright; dev@subversion.apache.org Subject: Re: Static code analysis (cppcheck) Julian Foad julian.f...@wandisco.com writes: [SVN\subversion\libsvn_auth_kwallet\kwallet.cpp:203]: (style) Variable 'app' is assigned a value that is never used [SVN\subversion\libsvn_auth_kwallet\kwallet.cpp:273]: (style) Variable 'app' is assigned a value that is never used To remove the warning I suppose we could drop the app variable, i.e. new QCoreApplication(...) instead of app = new QCoreApplication(...) Better would be to tell cppcheck you know this is ok and to ignore it by enabling the suppression filter for this false-positive. Put the following on the command line : --suppress=errorid:kwallet.cpp:203 Easiest way to get the error id is to use the --xml output type. You can remove the line number from that suppress command to suppress all of those errors in the file, and you can set these in a file and use --suppressions suppressions.txt (all in chapter 6 of the manual) Andy
RE: Case-only renames on Windows (issue #3702)
-Original Message- From: Branko Čibej [mailto:br...@xbc.nu] On Behalf Of Branko Cibej Sent: 24 March 2011 15:32 To: dev@subversion.apache.org Subject: Re: Case-only renames on Windows (issue #3702) [snip] In short, things aren't /that/ tricky as far as renames go. They're a lot trickier during update and commit, if the editor hits a local file that has the wrong case on-disk, but is otherwise versioned (I've known brain-dead tools to case-only rename the files they'd worked on). -- Brane Now you've reminded me of something, those brain-dead tools that rename files you have under svn, and when you come to commit them, they get ignored because the system think's they're new files. TortoiseSVN has some special-case handling for these, try to commit one of them and Tortoise will pop up a messagebox asking if you want to rename the case and retry the operation (and gives you a menu option to rename files directly). http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-rename.html Of course, the best approach would just to make the entire system case-insensitive and cater to the lowest common denominator (after all, the http transport should be case-insensitive too, I get to the same place typing in www.apache.com or www.APACHE.com, but not when it comes to the svn repo url).
RE: [PATCH] Fix for issue 3799 - exporting file should not overwrite
-Original Message-
From: Julian Foad [mailto:julian.f...@wandisco.com]
Sent: 25 February 2011 15:33
To: Noorul Islam K M
Cc: Subversion
Subject: Re: [PATCH] Fix for issue 3799 - exporting file should not overwrite
On Sat, 2011-02-19, Noorul Islam K M wrote:
I think it is this way
If specified target ('/tmp/iota' in the example above) is a ...
nothing - fine
file- if 'force' then overwrite else error
symlink - if 'force' then overwrite else error
special - if 'force' then overwrite else error
dir - if sub-target ('/tmp/iota/iota') is a ...
nothing - fine
file- if 'force' then overwrite else error
symlink - if 'force' then overwrite else error
special - if 'force' then overwrite else error
dir - error cannot force
(That's all when the source is a file; a dir is handled differently.)
OK, that looks good. I agree that that would be a good behaviour to
implement.
My 2p:
Why would we want dirs to be handled differently? Surely, we want the behaviour
to be as expected as possible, and if file export behaves differently to
directory export... that's not so good.
Also, does this work as intended when using externals? I recall trying to
export directories using externals to the same location on the filesystem and
finding that each external wiped the target before copying the files (imagine
you have several C modules and want to export all the headers from each of them
to a single include directory, as an example of what I was trying to achieve).
RE: [Feature] New feature about handling 'HTTP Error 302 Movedtemporarily'?
-Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: 28 January 2011 19:03 To: Bolstridge, Andrew Cc: dev@subversion.apache.org Subject: Re: [Feature] New feature about handling 'HTTP Error 302 Movedtemporarily'? Bolstridge, Andrew wrote on Fri, Jan 28, 2011 at 12:46:40 +: On 01/27/2011 08:27 PM, Wu Di wrote: I found path in subversion sometimes too long, it's hard to be sent by Email and something else. And 'Tiny URL' is more popular now. it redirect a short URL to a long one. I thing is a good idea if TortoiseSvn could handle 'HTTP Error 302 Moved temporarily' to support Tiny URL and something like that? Just as long as it doesn’t use a 3rd party redirection service that may (or may not) continue to be available in the future - eg. tinyurl.com or bit.ly or similar. Don't those services use 301 redirects? It doesn’t matter how they redirect as the association between the short-code and the real url has to be stored somewhere, so if the url-shortening service goes down (or is switched off for whatever reason - maybe someone decided they have a patent on url shortening, or they just stop making money, or get bought out by Oracle or whatever)(it's happened, look at evilurl.com) then the short urls stop working. In fact, download a tinyurl link (eg their example, http://tinyurl.com/6 and open it in an editor. Be prepared to be amazed :)
RE: [Feature] New feature about handling 'HTTP Error 302 Moved temporarily'?
On 01/27/2011 08:27 PM, Wu Di wrote: I found path in subversion sometimes too long, it's hard to be sent by Email and something else. And 'Tiny URL' is more popular now. it redirect a short URL to a long one. I thing is a good idea if TortoiseSvn could handle 'HTTP Error 302 Moved temporarily' to support Tiny URL and something like that? Just as long as it doesn’t use a 3rd party redirection service that may (or may not) continue to be available in the future - eg. tinyurl.com or bit.ly or similar.
RE: Windows svnsync test suite failures and a clue
-Original Message- From: Paul Burba [mailto:ptbu...@gmail.com] Sent: 21 December 2010 22:56 To: Subversion Development Subject: Re: Windows svnsync test suite failures and a clue [snip] Being somewhat incredulous that this was the problem, I reinstalled WLE2011 and sure enough the tests failed again. After uninstalling, the tests again worked. So WLE2011 is the problem. Why is it a problem? I don't know, and since I don't really require these apps, I'm not going to spend any more time at the moment trying to figure it out...I'm retiring from the mysterious Windows failure game for the rest of 2010 ;-) Paul Nope, I believe it completely. We had certain issues with Trend anti-virus recently, on a 64-bit Win7 box with only windows live *messenger* installed, it would corrupt the AV and be unable to repair. Since then further updates to WLM have fixed the problem. No-one knows why it’s a problem, and I think MS quietly fixed whatever system instability it was causing.
RE: How to get the message out (or: why there were only 6 people at the ApacheCon meetup)
-Original Message- From: C. Michael Pilato [mailto:cmpil...@collab.net] Sent: 09 November 2010 16:42 To: Hyrum K. Wright Cc: Bolstridge, Andrew; Subversion Development Subject: Re: How to get the message out (or: why there were only 6 people at the ApacheCon meetup) On 11/09/2010 10:35 AM, Hyrum K. Wright wrote: On Mon, Nov 8, 2010 at 9:39 AM, Bolstridge, Andrew andy.bolstri...@intergraph.com wrote: I'm sure evangelical missions are still important - mainly to counter the SVN is crap at merging, Mercurial/Git/a.n.otherDVCS is the ultimate SCM that fixes all your problems type arguments that seems to be increasingly popular. Even our Serena dimensions admin (terrible 'enterprisey' ALM SCM) knows about git but doesn't know what SVN'd give him. So, I'd say there are still loads of poor souls needing the word bringing to them, and the FUD dispelling. Then aside from cold-calling all potential proselytes, what venues are the best places at which to talk to folks? Are there ALM or SCM or other types of conferences with which an evening Subversion event would work well? (Or is this type of thing better left to marketing departments instead of us technical peeps?) I think some of this starts with Subversion supporters being more vocal. Do we actually believe that SVN is crap at merging, Mercurial/Git/a.n.otherDVCS is the ultimate SCM that fixes all your problems is FUD? If so, we should be calling it out as such. This is not a battle for Marketing departments to wage, because the folks that need to hear the message don't care one lick for the latest output from those folks. (Honestly, when was the last time any of us got excited about some new technical thing because we read a press release about it?) Subversion didn't land on a bunch of CTOs' desks and get implemented as a corporate mandate. It took root with individual users who are more attentive to Slashdot-like buzz than press releases; folks who are more likely to try something based on their buddies' recommendations than on what has the slickest booth at a trade show. DVCS will infiltrate the current Subversion base in exactly the same way. If we seek to defend Subversion's relevance and utility, we'll have to do so in a technical communications ground war. And we'll have to do so while continuing to innovate and improve the software itself, closing down those pain points that cause our users to have wandering eyes in the first place. I'm sure you've seen this: http://www.joelonsoftware.com/items/2010/03/17.html and the link to http://hginit.com/ that he wrote to evangelise mercurial (over svn. The links are both basically saying 'look how much better hg is over svn, even when his merging tutorial is pretty much exactly what I'd do with svn!) *This* is what I mean by FUD. Martin Fowler redresses the balance, but in a matter-of-fact way: http://martinfowler.com/bliki/VersionControlTools.html In fact, he gives 3 reasons to use a DVCS: Faster operations on history, because you have a copy of the entire repo, you can see a log quickly. Perhaps this can be solved in SVN by downloading more of the metadata (eg log) in much the same way as the last revision is stored locally to give you fast diffs. Better management of branches - in particular, much easier to branch, work, then delete the branch as if it never was. This is analogous to developer branches in SVN, but that never show up to others - SVN can get very full of branches (and tags!) if you let it. local development that can be committed at a later time, eg you can 'commit' even without a network. He doesn’t include merging, which is something that everyone says is so simple and easy in a DVCS compared to the pain that is SVN. I treat this as FUD, though usability of merging is something that could be better (as always) and tree-conflicts need to be dealt with better. I think that an enhancement such as merging 1 change to multiple branches would be truly special for a corporate who often has legacy versions to maintain. Interestingly (to me, at least), while the typical corporate user is happy to absorb recommendations from the blogosphere and pull those into their corporate environments, they are absolutely *horrific* at communicating back *outward*. Here is where the corporate sponsors of this project still have a crucial communications role to play. As the primary liaisons with that whole (very large) class of user, it's important that companies such as CollabNet and elego and WANdisco and [[insert your company here if you depend on Subversion, too!]] continue providing this community with insight into the reasons why DVCS is getting a foothold in the corporate environment as well as with the resources to do something about it. I'll tell you that I introduced SVN into our company 2 years ago after evaluating it and a few others. Since then its
RE: Translation help
-Original Message- From: hy...@hyrumwright.org [mailto:hy...@hyrumwright.org] On Behalf Of Hyrum K. Wright Sent: 15 November 2010 18:17 To: Subversion Development Subject: Translation help To any current and/or interested translators: In an effort to make translation of Subversion easier, and more complete, I've installed an instance of Pootle, a web-based translation tool. You can access it here: http://translate.hyrumwright.org/projects/svn/ -Hyrum Nice find, we're thinking of investigating it to see if it would help our internal translation efforts! My colleague Kim might help with a Danish translation, but he is busy so wouldn't be able to commit fully to it - so, would it make sense to put a translation project for Danish on that site so he could dip in as he has time. (no doubt when he sees a target to aim for, he'll be more encouraged to finish them all :) ) Obviously it wouldn't be released until complete, but - if an empty translation is visible, people might contribute more than if they had to commit themselves, so as a tool to assist translation - it's can only help.
RE: How to get the message out (or: why there were only 6 people at the ApacheCon meetup)
-Original Message- From: hy...@hyrumwright.org [mailto:hy...@hyrumwright.org] On Behalf Of Hyrum K. Wright Sent: 07 November 2010 02:34 To: Subversion Development Subject: How to get the message out (or: why there were only 6 people at the ApacheCon meetup) [snip] My question: do we need to do this? Is there a niche that isn't being filled by the various corporate sponsors, which we (as a Subversion development community) are better served to do? Do people already know enough about Subversion, such that we don't need to evangelize anymore? I'm sure evangelical missions are still important - mainly to counter the SVN is crap at merging, Mercurial/Git/a.n.otherDVCS is the ultimate SCM that fixes all your problems type arguments that seems to be increasingly popular. Even our Serena dimensions admin (terrible 'enterprisey' ALM SCM) knows about git but doesn't know what SVN'd give him. So, I'd say there are still loads of poor souls needing the word bringing to them, and the FUD dispelling.
RE: object-model: Return by value, reference or pointer? (or something else?)
-Original Message- From: Steinar Bang [mailto:s...@dod.no] Sent: 13 October 2010 21:16 To: dev@subversion.apache.org Subject: Re: object-model: Return by value, reference or pointer? (or something else?) Do you need the distrinction between an empty string and a NULL? If not then I would return an empty string for a NULL on the C side. There's also the consideration that some std::string implementations are deep copying (the gcc version uses refcounting (or at least used to do so), but the VC++ one used to use deep copying. I'm not sure if that still is the case). -- Yes, it does, they removed refcounts after VC6. The problem with refcounting a std::string is the performance of it in a threaded environment is worse than simply copying the string (you have to handle all the copy-on-write issues and this gets difficult). http://www.sgi.com/tech/stl/string_discussion.html describes some of the problems. I have agree with Steiner - what's the difference between a null string and an empty string? Typically there is no difference. In the case of C there was, as the char* might be NULL, or it might point to a byte with \0 as its first character. That NULLness is an artefact of how C manages string memory, not any way of describing the string. Once you start using both, you get stuff like .NETs '.IsNullorEmpty()' methods - and then you're back right where you started, treating a NULL and an empty string as the same thing. In C++, if you really need to return either nothing or a string, return a std::pairbool, std::string (like std::map uses to indicate if the insertion succeeded or failed due to an existing key was already present in the map). Most DB access methods return the datatype, and another indicator whether the data was NULL. Personally, I would stick to just returning a string, or if it is essential to return a null value, return a string and an null indicator - your choice whether that's best as a pair, or an out parameter. I would not inherit from std::string, nor would I throw an exception (not that anyone's yet suggested that - we're not C# or Java programmers after all :-) ) Andy
RE: place of svnrdump
-Original Message- From: Ramkumar Ramachandra [mailto:artag...@gmail.com] Sent: 27 September 2010 19:58 To: Neels J Hofmeyr Cc: dev@subversion.apache.org; Daniel Shahaf; Stefan Sperling Subject: Re: place of svnrdump Neels J Hofmeyr writes: While we're at it... svnsync's slowness is particularly painful when doing 'svnsync copy-revprops'. With revprop changes enabled, any revprops may be changed at any time. So to maintain an up-to-date mirror, one would like to copy *all* revprops at the very least once per day. With a repos of average corporate size, though, that can take the whole night and soon longer than the developers need to go home and come back to work next morning (to find the mirror lagging). So one could copy only the youngest 1000 revprops each night and do a complete run every weekend. Or script a revprop-change hook that propagates revprop change signals to mirrors. :( Of course, you could put a post-revprop-change hook in place to note which revprop was changed, and then run a script that only syncs those revprops. I wouldn't recommend putting the 'sync copy-revprops' command in the post-revprop-change hook, if someone commits a revision then immediately updates the revprop the sync will fail (as the rev may not have been synced yet). If anything, changing svnsync to ignore a failed copy-revprop command if no revision existed to sync to would fix this problem, and the copy-revprop could then be put in the hook without worry.
RE: Pascal bindings
-Original Message- From: C. Michael Pilato [mailto:cmpil...@collab.net] Sent: Thursday, September 02, 2010 7:47 PM To: Philip Martin Cc: dmitry boyarintsev; dev@subversion.apache.org Subject: Re: Pascal bindings On 09/02/2010 01:38 PM, Philip Martin wrote: dmitry boyarintsev skalogryz.li...@gmail.com writes: Hello Subversion-dev, I can see, that there's no much of interest in Pascal bindings. Well, that's quite understandable because of Pascal language not being popular. Anyway, I'll publish the headers on my site. Thank you for your great product! You are more likely to get some response if you send a patch against trunk with a log message, see http://subversion.apache.org/docs/community-guide/general.html#patches Even if you do that I don't know that there is any great demand for Pascal bindings. Are they generated or written by hand? Do they have regression tests? Are they tied to any particular environment? All great questions, Philip. Another one that's on my mind is, Is Dmitry volunteering to stick around and maintain these bindings? We really try to avoid drop-and-ignore contributions of this sort, where none of the active committership appears to be interested (or perhaps even qualified) to maintain the new code. While that's an ideal position to be in, isn't there room for a 'second class' addition to the main codebase where the code is present, hopefully working, yet comes with no warranty or is part of the automated test set. The alternative is that valuable code would end up being posted to some website and wouldn’t have the visibility in the future if someone did come along, decided that they wanted the feature, and then spent the effort to fix it up (assuming it was broken). As was mentioned, the python bindings were not maintained until recently when someone did send contributions in. If the python bindings were not present at all, this would not have happened. So I'd say a pragmatic approach would be to take the contribution, and place it off to the side slightly compared to the 'tested, maintained' codebase and have the tests available to run manually. Maybe if someone comes along to maintain the code, then it can be moved to being a 'full' member of the codebase. not that that is an issue in this case as Dmitry says he will actively maintain it, and other C bindings, although it appears he is already slightly alienated from contributing given his response.
RE: Bikeshed: configuration override order
-Original Message- From: Julian Foad [mailto:julian.f...@wandisco.com] Sent: Tuesday, August 10, 2010 6:25 PM To: C. Michael Pilato Cc: Bolstridge, Andrew; Subversion Development Subject: Re: Bikeshed: configuration override order [snip] Oh? All I know about Andrew's particular requirements related to this query is what's quoted above - If I ... accidentally leave the banned buildlog.htm file in ... - which sounded vaguely like a requirement for a path-based rule. Maybe I missed something. Drats! My hopes that an invalid commit might go faster because I'd made a mistake in understanding the hooks was cruelly dashed. In a way it is a path-based rule - I want certain file extensions (eg. *.obj) , certain directories (eg Debug) and certain explicit files (eg buildlog.htm) to be barred from the repo. I used buildlog.htm as an example because it's easy to flip through the list to commit and mark the obvious ones off, but not so easy to keep all htm files, except that one. Still, the client global-ignores is great, I just want to store it on the server. The second aspect: client-stored passwords, this isn't so much about storing them on the client but about having different ones. Enterprises want single-signon, ie, a single password, centrally held, that is used for all apps. They don't really care about storing it locally so much as caring when Mildred calls the helpdesk to say her password doesn’t work only to find she's changed her main login but her svn password is the old, different one. I don't think there's much to do here, except to get LDAP working. Fortunately, VisualSVN allows integrated authentication with Active Directory, and most enterprises still use Windows. It's still all about centrally-held configuration and not having to discover what a client may or may not happen to be using.
RE: Bikeshed: configuration override order
Summary... There are two issues here... 1. The repo admin wants to enforce what is commited to their repo. This exists with scripts but common request can be made inherient repo settings (probably need to be path based). The issue with pre-commit hooks is that they are run after all data is transferred - so if I commit loads of data, and accidentally leave the banned buildlog.htm file in... I'll find out about it after half an hour's commit.. and have to repeat the process. It's not that major an issue but repo-set config would fix it. Auto-props is a more tricky problem that would just be nicely solved by telling the clients what settings to use. 2. The admins want to simplify config for clients committing to repos that have various enforcements made (see item 1) without needing to deal with distirbuting client config files or what have you. This is the biggie - one remote worker decided he didn't have to read all the email I sent him on how to set up svn, and ended up committing 2 Gb of crud to my lovely repository. We have a pre-commit hook for all file extensions now. Perhaps the ideal (and easiest) way to resolve all this is to have the repo inform the client of mandatory settings that it expects to be set, and perhaps optional ones, and either automatically download a new set of configs to the client, or have the client fail until its config is in compliance with the repo's configuration settings. A new option could be added to the client to download and use the config from the repo. This could be made automatic, every time the client runs a repo-contacting command, it gets a hash or guid from the server that describes the config, and if that doesn't match what the client has, the client can run the config-download in the background (and then re-try the command it was trying to do). Perhaps allow the client to store multiple config files and use the one that matches the repo, along with the default one that we currently have. The server config can then only set the bits it wants, missing config options are used from the default. There's scope in there for the client to download the repo's chosen settings, and then override them anyway. There's scope for the repo to mandate a few options, giving the client a choice of going to play elsewhere or accept the restrictions. Anyway, that's my thoughts on the subject. Repo-driven config, even if its just an easy way to download a new set to the client instead of the email 'use this file, or use this registry script' is a huge step forward. Andy
RE: Suggestion: Transparent Branching
-Original Message- From: Branko Čibej [mailto:br...@xbc.nu] Sent: Thursday, July 29, 2010 10:05 AM To: dev@subversion.apache.org Subject: Re: Suggestion: Transparent Branching On 07.07.2010 18:29, Greg Hudson wrote: On Wed, 2010-07-07 at 11:44 -0400, Marco Jansen wrote: So therefor, what we would like to see is to be able to have a transparent branch: One which fetches updates from both branch and trunk, without having them listed as changes or triggering commits. In essence it's reading from two branches, where a last known revision of a file could be from either branch, and committing to one only when it has changes from this 'either' latest revision. I'm not sure if this is a feature of any popular version control system. What would happen if trunk changes didn't merge easily with the changes on one or more transparent branches? ClearCase and AccuRev come to mind. AccuRev might not be that popular, but ClearCase definitely is. Ahh, I think you refer to Pass-through streams, where an individual file is branched and changes to that file occur on the branch, but changes to all other files occur on the trunk where the branch was initially created. It’s a powerful idea (especially when you come to work with partial inclusion or exclusion filters) but requires a powerful view to keep track of what you're changing and a good system for keeping track of a branch's parent(s). Eg. I have a directory structure like: /Framework and /Framework/Plugin. I branch the plugin directory so I can work on that, but I still see the full directory structure. If I make changes to anything in the Framework directory, it occurs on that branch that is shared by all. If I make a change in the Plugin directory, only I see the change until I merge it back. I think it's possible SVN could manage this with a 'redirect' property that sends any commit/update operations to a specified revision. So you still branch as usual, but any operation on a directory would be made to apply to a directory elsewhere in the repo.
RE: [PATCH] new feature, lazy sync via export --skipfilesmatchingsize
-Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Monday, July 26, 2010 3:34 PM To: svnusert...@href.com Cc: dev@subversion.apache.org Subject: Re: [PATCH] new feature, lazy sync via export -- skipfilesmatchingsize [snip] I don't know if there is interest in providing a feature for svn export which allows exclusions of files from the export based on user-definable criteria (which could include files size). Such a feature might stand a better chance, but would be significantly more work to accomplish. Did I miss something, but wasn't the original spec don't export files that are already on disk. Sure, that's not so far from 'don't export files based on criteria xyz, but its sufficiently different to be important. Ie. This isn't a filter mechanism, it's an optimisation designed to prevent unnecessary copying of data. Now, it might be that the filter isn't sufficient to detect whether a file is the same or not (and it might require timestamp or md5 support too), but I think this is a valuable option to have. If you have a directory full of source files, and it contains a sub-directory full of almost-never-changing, large binary files, then it would be great to initiate an export and have it recognise the binaries haven't changed and so don't need to re-downloaded over the top of the existing files. The flag could be better worded and the algorithm used to detect un-changed files may need making more robust, but otherwise I think it's a worthwhile addition. Next - export multiple times into a directory containing files without deleting any of them :) Andy
RE: Suggestion: Transparent Branching
-Original Message- From: Marco Jansen [mailto:sart...@gmail.com] Sent: Wednesday, July 07, 2010 4:44 PM To: dev@subversion.apache.org Subject: Suggestion: Transparent Branching Greetings, The issue we have is that we use trunk as a stable version, but with ongoing maintenance. Quick bug fixes to improve stability are generally directly committed to trunk, and sometimes even rapidly deployed from trunk. Surely you just want to merge only the revisions that were changed on the branch, not those that were merged from trunk. Doesn't mergeinfo help you here? If not, if you marked each revision that was merged, wouldn't that allow you to skip those when merging back to trunk? Extended changes, often longer-term projects, are supposed to go in branches. The biggest problem is that these branches do not automatically receive the maintenance and fixes committed to trunk. Ofcourse, there is a known work-around for this: Merging trunk into the branch; and this could even be automated with a script-hook. It still poses a problem that this merge is considered a change from the branch's viewpoint, and therefor gets committed on its own in a seperate revision in the branch once more, while all it is is an update from trunk. This often complicates the final merge from branch back to trunk, since the changes have been committed in both. I do like the idea of 'automatic' merges to multiple destinations. So I would branch 2 times from trunk, then I could make a change to trunk and have that change cascade onto both branches (ie without performing 2 separate merges). That'd be pretty cool, though I don't know if it's possible or really desirable :) So therefor, what we would like to see is to be able to have a transparent branch: One which fetches updates from both branch and trunk, without having them listed as changes or triggering commits. In essence it's reading from two branches, where a last known revision of a file could be from either branch, and committing to one only when it has changes from this 'either' latest revision. Sounds like a bodge of a suggestion - you want a view of the repo where 2 branches are seen as 1, the latest revision from either is used? So if trunk was updated, it would suddenly take precedence and obscure the same file on the branch. That sounds like a good way to screw whatever it is you're working on, as your WC could change at any time - all those changes you made to branch suddenly disappeared and you see the file from trunk. Not good, and confusing as hell.
RE: Problem building Serf on Windows
-Original Message- From: Mark Phippard [mailto:markp...@gmail.com] Sent: Monday, July 05, 2010 5:13 PM To: Subversion Development Subject: Problem building Serf on Windows I am setting up a new Windows build machine. I am building our 1.6.12 release and deps zip. I get a problem when it goes to build Serf. Performing Makefile project actions context.c context.c(585) : error C2036: 'void *' : unknown size context.c(1410) : warning C4090: '=' : different 'const' qualifiers NMAKE : fatal error U1077: 'c:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe' : return code '0x2' Stop. Project : error PRJ0019: A tool returned an error code from Performing Makefile project actions Any ideas? Cast it to a char* or a BYTE*. http://msdn.microsoft.com/en-us/library/1kay26wa%28VS.80%29.aspx some compilers assume a 'void' type is a char/byte type and treat it accordingly. MS compiler doesn't do that, it (possibly correctly) treats a void as a 'non type' without a size. The workaround is to explicitly tell it what size to use.
RE: auto-upgrade of working copy
-Original Message- From: Alan Barrett [mailto:a...@cequrux.com] Sent: Thursday, July 01, 2010 8:26 AM To: dev@subversion.apache.org Subject: auto-upgrade of working copy [snip] The auto-upgrade has always bothered me. I'd much prefer to have a command line action (e.g. svn upgrade) to upgrade the working copy, and for the default behaviour to be that the client prints an error message suggesting that the user should run svn upgrade. Many people use different clients in the same working copy (e.g. a command line client and a GUI client), and it's a pain if one client decides to upgrade the working copy to a format that the other client doesn't support. Can I second this - a little while back TortoiseSVN was upgraded to svn 1.6, but AnkhSVN hadn't been recompiled to use it - as a result, working copies could not be used by Ankh in Visual Studio, or if you wanted to use AnkhSVN, you had to stop using the new TortoiseSVN. The guys at AnkhSVN did issue a new version, but only after a few weeks. Next time, I would manage a rollout of 1.7 clients now, waiting until all clients we use had been upgraded before blindly upgrading as soon as the new version was available. That's probably the best system to use, and an auto-upgrade would be preferable. If the release notes gave a big warning reminder about this, that might be the best means of managing WC upgrades.
RE: First SVN performance data
-Original Message- From: Stefan Fuhrmann [mailto:stefanfuhrm...@alice-dsl.de] Sent: Wednesday, May 12, 2010 7:08 PM To: dev@subversion.apache.org Subject: First SVN performance data Hi there, as I promised, I'm going to conduct some in-depth analysis and comprehensive SVN performance testing. That is very time-consuming process. However, it seems that many people have incorrect or outdated ideas about the current state of affairs. To add a bit more substance to the discussion, I like to present some preliminary data and not to wait until I collected all data I intend to. Side note: Maybe, these numbers make it clearer why my patches should be committed after review. Bottom line: * SVN servers tend to be CPU-limited (we already observed that problem @ our company with SVN 1.4) Lovely figures, but I'm guessing CPU will be more of a bottleneck when you run on a server with 24Gb RAM and 4 SSDs in RAID-0 configuration. The server will allocate so much to cache that everything is super-quick, and what disk IO there is, will also be super quick. Do you have benchmarks on a more 'representative' server? Say, a dual core with 2Gb RAM and 4 HDD disks in RAID5 running as a VM image, and SVN running over http?
RE: [PATCH] Saving a few cycles, part 2/2
-Original Message- From: hy...@hyrumwright.org [mailto:hy...@hyrumwright.org] On Behalf Of Hyrum K. Wright Sent: Wednesday, May 05, 2010 3:55 PM To: Peter Samuelson Cc: dev@subversion.apache.org Subject: Re: [PATCH] Saving a few cycles, part 2/2 ... I would agree. I saw the commit of Stefan's patch, and independently thought about using a lookup table (though I prefer Peter's implementation). I don't have any hard performance numbers, but I gotta believe the lookup table is simpler, as well as more performant. It may be simpler, but generally not as fast as arithmetic. The problem (with modern processors) is that the table (or the entry you want) has to be loaded into the CPU cache and that may require a main RAM access that is very slow (relatively speaking) compared to a few maths operations. For example, you can do many instructions per clock cycle, but fetching 1 byte from main RAM (at 10ns delay) will take 30 clock cycles on a 3Ghz chip (and that's a lot of maths instructions over a thousand). I think it takes a lot longer than that, with slower latency RAM we use today and 3 levels of cache. But the point is that a lookup table is no longer necessarily faster than calculating the data. How times have changed :) Anyway, it's hardly going to be a big deal to overall performance, so whatever is easier to maintain is best.
RE: Feature idea: user-configurable post-commit notifications
-Original Message-
From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
Sent: Mon 26/04/2010 19:27
To: Bolstridge, Andrew
Cc: dev@subversion.apache.org
Subject: RE: Feature idea: user-configurable post-commit notifications
Bolstridge, Andrew wrote on Fri, 23 Apr 2010 at 13:52 +0100:
So imagine if I (as a server admin, of course) could configure a new
command (svn review or svn special-cmd review) that uses the
same mechanism as pre-commit, and calls the server hook
special-review.pl. That's 3 data items in server and client
configuration - ('review', 'pre-commit', 'special-review.pl').
Just to clarify: I assume you intend that script to be run on the server
(using data provided by the client)?
Yes, all on the server - exactly like the existing infrastructure.
I'm not suggesting any of this be run on the client.
RE: Pushmi support
-Original Message- From: hy...@hyrumwright.org [mailto:hy...@hyrumwright.org] On Behalf Of Hyrum K. Wright Sent: Friday, April 09, 2010 9:58 PM To: Stefan Sperling Cc: Philip Martin; Tim Starling; Greg Stein; Subversion Development Subject: Re: Pushmi support The last thing I want to do is add more process (someones earlier comments about HACKING are quick illuminating), but it might be worth creating a template for such a document and posting it somewhere. I don't think we need to go the full route of PEPs, but having some way to track design proposals with more finesse than the issue tracker would be nice. Collabnet's TeamForge?
RE: Subversion Vision and Roadmap Proposal
-Original Message- From: Vadim Chekan [mailto:kot.bege...@gmail.com] Sent: Friday, April 09, 2010 9:14 AM To: Subversion Development Subject: Re: Subversion Vision and Roadmap Proposal P.S. Plase, introduce true tags, no more lets pretend this copy is a tag. I agree here - branches are great, but sometimes you want a 'snapshot' or a 'baseline' that doesn't require a whole new directory in the repo (especially as the number of branches you have increases, things start to become less manageable - just the nature of having lots of things)(for example, we have 300 projects in our repo and we release very regularly. Creating a branch for each release would be a bit messy after just a few - not to mention the problems of deciding how to structure the repo to account for all those projects, do we put branches at the root and have a huge list of releases that require special naming conventions, or branch at the project level and miss the interdependencies between them. All tricky stuff for the branching mechanism). And yes, I know this has been gone over many times in the past.
RE: Subversion Vision and Roadmap Proposal
ROADMAP With that vision in mind, we identified a number of high-value improvements which Subversion should gain in coming releases. Then we took a casual pass at assigning some technical plumbing dependencies for each of these. Here's what we came up with, in the form FEATURE: [DEPENDENCY ...], where FS-NG = major FS backend overhaul, WC-NG = WC-NG, and Ev2 = svn_editor_t: * Obliterate: FS-NG * Shelve/Checkpoint: WC-NG * Repository-dictated Configuration: WC-NG (?) * Rename Tracking: WC-NG, Ev2, FS-NG (?) * Improved Merging: WC-NG * Improved Tree Conflict Handling: WC-NG, Ev2, Rename Tracking * Enterprise Authentication Mechanisms: * Forward History Searching: FS-NG (?) * Log Message Templates: Repository-dictated Configuration COMMUNITY But communication alone isn't enough. We need to find ways to grow our developer community itself. Attendance at the recent Subversion Corporation Annual Members Meeting was low (by design and recommendation, of course), but a startling realization was made there. When the agenda item for voting new full committers into membership was on the table, there were no candidates. Think about that: no new full committers for Subversion in the past year. This is a bad thing. We need to find a way to embrace and empower would-be Subversion contributors. SUMMARY I've covered a lot of ground here, but decisions in this community have always been and will be made on this mailing list, and they deserve to be made with as much information as possible. You now know where a small contingent of developers stand on these issues. I'd like to publicize on our project website a *community-endorsed* vision and roadmap ASAP, and then get to the business of moving Subversion forward along those lines. So what say you? Well, I (as an outsider to the svn dev community) say great! My thoughts on this: firstly, to attract more people to the community, you need to go where they are. This dev mailing list is all well and good for subversion developers, but that's exactly the audience you've already got. I think this roadmap/vision/invitation needs to be posted elsewhere, even if watered down. If you want suggestions for things to add to the roadmap then post to stackoverflow.com and serverfault.com and see what the people there come up with (I'll happily create such posts if you want me to) I think other main issues are: Repo-dictated configuration (worth saying again, this is more important than you think) General performance, especially with lots and lots of files (I need to work with 20,000 for one project - it doesn’t work, I have to commit individual directories instead. The failure when trying looked really bad when my boss watched it once. If I was a manager and saw that, I wouldn’t allow subversion to be used for my team). Baselining (branches everywhere doesn't really meet many corporate requirements as we have a lot of projects in our repos, while I love the visibility of branching in svn compared to many lesser SCMs, there is still a problem with managing multiple branches - it's too easy to create a huge 'directory structure' of branches. If you have 300 projects in your repo, you can see how it quickly gets out of hand. This is probably why there's so much heat in past discussions of tagging), Searching in the repo - it's not that we need a new FS backend, but an index on that. After all, the repo files don’t often get touched unless you want to see old versions but the history associated with them does. So really, the revprops need a different format. That'd probably be sufficient for a perf boost for most tasks. To get new developers, I think the first thing that needs to be done is to make entry easier. That means providing a setup ready-to-debug for people. The initial hurdle on any software project is getting set up (I find) so if you could release a VM image with everything set, or a visual studio project with the code and dependencies in there ready for someone to press 'compile', then you've made a massive headway to helping new devs get going. A pre-built Windows solution would be the ideal - if anyone has one already... let us know :) The documentation could be better (as always :) ), but getting the code running in a debugger is probably documentation enough, especially for a new developer who wants to modify things. Good news on this email though, I love subversion and just look forward to making it better. Andy
