Re: Format bump for 1.8?
Johan Corveleyn wrote on Thu, Jul 12, 2012 at 23:29:06 +0200: On Thu, Jul 12, 2012 at 10:56 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: Johan Corveleyn wrote on Thu, Jul 12, 2012 at 22:19:50 +0200: On Thu, Jul 12, 2012 at 7:31 PM, Peter Samuelson pe...@p12n.org wrote: [Markus Schaber] So my personal experience tells me that multiple-client scenarios are the common case, and that the deployment strategy (only using linux distro packages, or 3-in-1 bundles like VisualSVN) can reduce that problem. So, we provide a pile of libraries that maintain ABI backward compatibility. You can have as many different svn client apps on a given system as you want, and so long as they are all using the same copy of our libraries, there is no cross-version compatibility problem. (Of course, there's two other related issues: 1) sharing a wc across two or more systems; 2) use of SVNKit. I'll ignore both for now; SVNKit in particular is, and should be, Somebody Else's Problem anyway.) I think it's sad that there is so much antagonism against SVNKit in this community. With my svn user hat on, I consider SVNKit as just another part of the svn ecosystem. As a user, I don't really care if it's implemented in C, in Java or in Turbo Pascal :-), as long as it plays by the rules and acts like any other svn client. Besides, in our environment I have no choice but to use SVNKit: the svn plugin of my IDE (IntelliJ IDEA) only works with SVNKit. I think it would be beneficial for the svn ecosystem as a whole if this community would try to build better relations with the SVNKit people. Some mutual understanding certainly wouldn't hurt. I was very happy to see more interest by the SVNKit guys in the core project, and see their presence at the Berlin Hackathon (hi Dmitry :-)). I don't think there is antagonism against svnkit here; just they chose not to use our APIs, so if things break because of that it's their problem to fix and not ours. To restate what I said on IRC: things are not breaking because of SVNKit (they easily support all working copy formats back to 1.3 with their 1.7 client), it's because of the native clients :-), that insist on upgrading themselves (nagging the user that there is a new version that they should upgrade to) and on upgrading the working copies. Combined with the fact that some software of the user depends upon SVNKit for their svn support, and SVNKit's release was lagging behind for 1.7. But I'm trying to state the problem more generally: most users have different clients, and those can have different release cycles. For whatever reason. I think it's naive to ignore that problem. Okay. But in that case, the problem you claim is disregarded has nothing to do with svnkit... I guess this is theoretically possible. But as a Windows user, I personally wouldn't like it. This is exactly one of the things that annoys me every time when I'm working on e.g. Solaris: What? I can't have two different svn versions installed at the same time? On my central build server with 1000 working copies I can't just quickly install a 1.7 version to do some tests, while all my colleagues keep on running svn 1.6 for the real stuff. Gah. Of course you can, just don't install it to the same $prefix as everything else. On svn.apache.org we have 6 different svn installations... Okay, maybe I can. But it's hard, especially because I'm not a sysadmin myself on that system, can't build from source, so I have to depend on installable third-party packages (Solaris packages in this case). But okay, maybe this is going a bit in too much detail about my particular situation ... don't want to bring in my organizational problems into the equation :-) ... But on Windows, I could just zip some svnclient from another system, and unzip it into C:\Temp or whatever, and test whatever I want. ./configure --enable-all-static ??? -- Johan
RE: [PATCH]: credentials are not saved if username differs from cached version but password does not
-Original Message- From: Dmitry Pavlenko [mailto:pavle...@tmatesoft.com] Sent: woensdag 20 juni 2012 18:15 To: dev@subversion.apache.org Subject: [PATCH]: credentials are not saved if username differs from cached version but password does not simple_providers.c (svn_auth__simple_creds_cache_get): I propose to drop all assignments need_to_save = FALSE except the initial one; otherwise assignment to FALSE may override existing TRUE value. This may happen if default_username!=username and default_password==password: in this case need_to_save will be FALSE. Not very popular case, I guess, but anyway. http://colabti.org/irclogger/irclogger_log/svn-dev?date=2012-06-20#l76 I also propose there (not covered by the patch) * either not to use 'have_passtype' at all * or always save credentials if have_passtype == FALSE Currently if have_passtype == FALSE (i.e. passsword encryption format has been changed) new credentials are saved only if old username differs from new username (whatever old and new passwords are). What do you think? [[[ Fix potential situation in which credentials are not saved to cache. If cached username and new username differ but passwords are the same, 'need_to_save' flag will be overwritten to FALSE, and new credentials fill not be saved. * subversion/libsvn_subr/simple_providers.c (svn_auth__simple_creds_cache_get): drop need_to_save = FALSE assignments. ]]] Patch applied in r1361123. Thanks for pinging on irc. Bert
Re: Format bump for 1.8?
On 12.07.2012 18:31, Peter Samuelson wrote: [Markus Schaber] So my personal experience tells me that multiple-client scenarios are the common case, and that the deployment strategy (only using linux distro packages, or 3-in-1 bundles like VisualSVN) can reduce that problem. So, we provide a pile of libraries that maintain ABI backward compatibility. You can have as many different svn client apps on a given system as you want, and so long as they are all using the same copy of our libraries, there is no cross-version compatibility problem. What? There definitely is, specifically in the case of the working copy library. Not on the API level, of course, but that's hardly where the WC-version problem stems from. That's why you have GUI clients that contain copies of several different versions of SVN's client libraries and pick the correct one depending on the version of the working copy they happen to be dealing with at any particular moment. And really, there's no reason why the Subversion command-line client shouldn't do the same thing -- in fact, this is by far the easiest way to support multiple working copy formats, even if it is less than optimal as far as installed binary size is concerned (not to mention release management and version juggling and testing). -- Brane -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: Avoiding multiple library copies on a system
On 12.07.2012 21:20, Peter Samuelson wrote: Reposting under a new thread + subject line, at Daniel's suggestion. [Markus Schaber] So my personal experience tells me that multiple-client scenarios are the common case, and that the deployment strategy (only using linux distro packages, or 3-in-1 bundles like VisualSVN) can reduce that problem. So, we provide a pile of libraries that maintain ABI backward compatibility. You can have as many different svn client apps on a given system as you want, and so long as they are all using the same copy of our libraries, there is no cross-version compatibility problem. Like I said in my response to this in the other thread -- API or even ABI compatibility is not the issue. Working copy formats, wire protocol quirks, etc. etc. are more interesting. And I really don't think it's up to us to tell packagers how to do their stuff. -- Brane -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: Format bump for 1.8?
On Fri, Jul 13, 2012 at 5:32 AM, Branko Čibej br...@wandisco.com wrote: ... And really, there's no reason why the Subversion command-line client shouldn't do the same thing -- in fact, this is by far the easiest way to support multiple working copy formats, even if it is less than optimal as far as installed binary size is concerned (not to mention release management and version juggling and testing). But why should we, as an open source project that only ships source code, worry about this? It sounds like a job for the folks that package binaries, either via OS package management systems or the various other binary providers around. If the solution you suggest is ship several versions of the libraries in the same binary, it just doesn't feel like something we should do (or worry about, frankly). -Hyrum
Re: Format bump for 1.8?
On Fri, Jul 13, 2012 at 11:10 AM, Daniel Shahaf d...@daniel.shahaf.name wrote: Johan Corveleyn wrote on Thu, Jul 12, 2012 at 23:29:06 +0200: ... But I'm trying to state the problem more generally: most users have different clients, and those can have different release cycles. For whatever reason. I think it's naive to ignore that problem. Okay. But in that case, the problem you claim is disregarded has nothing to do with svnkit... Indeed, and I never said it had (except as an example of a situation where you have multiple clients with different release schedules). I guess this is theoretically possible. But as a Windows user, I personally wouldn't like it. This is exactly one of the things that annoys me every time when I'm working on e.g. Solaris: What? I can't have two different svn versions installed at the same time? On my central build server with 1000 working copies I can't just quickly install a 1.7 version to do some tests, while all my colleagues keep on running svn 1.6 for the real stuff. Gah. Of course you can, just don't install it to the same $prefix as everything else. On svn.apache.org we have 6 different svn installations... Okay, maybe I can. But it's hard, especially because I'm not a sysadmin myself on that system, can't build from source, so I have to depend on installable third-party packages (Solaris packages in this case). But okay, maybe this is going a bit in too much detail about my particular situation ... don't want to bring in my organizational problems into the equation :-) ... But on Windows, I could just zip some svnclient from another system, and unzip it into C:\Temp or whatever, and test whatever I want. ./configure --enable-all-static ??? As I said, I don't have a build environment, don't have all the necessary dependencies, don't want to spend time figuring this out etc ... I'm looking for a binary distribution which I can just drop in my home directory and that will just work. But nobody seems to distribute all-static binaries for Solaris ... it's not the unix way, I guess. Anyway, this is probably digressing too much into a discussion of platforms and OS'es, things that we have no control over anyway ... -- Johan
Re: Format bump for 1.8?
On 13.07.2012 12:40, Hyrum K Wright wrote: On Fri, Jul 13, 2012 at 5:32 AM, Branko Čibej br...@wandisco.com wrote: ... And really, there's no reason why the Subversion command-line client shouldn't do the same thing -- in fact, this is by far the easiest way to support multiple working copy formats, even if it is less than optimal as far as installed binary size is concerned (not to mention release management and version juggling and testing). But why should we, as an open source project that only ships source code, worry about this? It sounds like a job for the folks that package binaries, either via OS package management systems or the various other binary providers around. If the solution you suggest is ship several versions of the libraries in the same binary, it just doesn't feel like something we should do (or worry about, frankly). I'm just saying it can be done, not that we should do it. On the other hand, looking specifically at supporting older WC formats in newer client versions -- that /is/ a feature that bears thinking about. -- Brane -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: Avoiding multiple library copies on a system
[Branko Cibej] Like I said in my response to this in the other thread -- API or even ABI compatibility is not the issue. Working copy formats, wire protocol quirks, etc. etc. are more interesting. And I really don't think it's up to us to tell packagers how to do their stuff. Well, the reason I bring it up is, if we expect everyone to bundle a copy of libsvn with every app, then our hard work to guarantee ABI stability is basically pointless. The whole reason to have a stable ABI is so people can upgrade libsvn without rebuilding or redownloading other apps. At some point we must have thought that was important. And if we did manage to achieve an ecosystem in which people are not bundling libsvn, the problem of multiple libsvn versions talking to a single wc would be greatly reduced. (Maybe not completely eliminated, as there's still the case of a wc on a network filesystem accessed from multiple clients machines.) That is why I wondered if there's any way we can get there, by encouraging people to take advantage of our ABI stability feature, which as I said we really do work hard to maintain. But it sounds like a lot of people really do prefer the vertical approach (every app bundles every library), in the Windows world, and there may not be much we can do about it. Peter
Re: Format bump for 1.8?
On Jul 13, 2012 6:30 AM, Branko Čibej br...@wandisco.com wrote: ... I'm just saying it can be done, not that we should do it. On the other hand, looking specifically at supporting older WC formats in newer client versions -- that /is/ a feature that bears thinking about. Feel free. I will state we already have support for them, and it is called 'svn upgrade'. :-) Cheers, -g
Re: Avoiding multiple library copies on a system
On 13.07.2012 17:21, Peter Samuelson wrote: [Branko Cibej] Like I said in my response to this in the other thread -- API or even ABI compatibility is not the issue. Working copy formats, wire protocol quirks, etc. etc. are more interesting. And I really don't think it's up to us to tell packagers how to do their stuff. Well, the reason I bring it up is, if we expect everyone to bundle a copy of libsvn with every app, then our hard work to guarantee ABI stability is basically pointless. The whole reason to have a stable ABI is so people can upgrade libsvn without rebuilding or redownloading other apps. At some point we must have thought that was important. This does not happen on properly managed (U|Li)nux distributions. It does happen on Windows, simply because there is no generally accepted location for globally shared libraries. Or rather, while Windows does provide mechanisms for component registration, they're a total pain in the unmentionables to use and don't apply co common or garden shared libs. Which brings us back to my assertion that it's not our job to do what packagers do best anyway. -- Brane -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: Measured: btrfs COW and sqlite exclusive locking
On 08.07.2012 17:47, Mattias Engdegård wrote: The biggest surprise was that COW actually made the checkout slightly slower, even though no true file copies were made. I'm not sure how to explain this---perhaps everything is already in cache so the copies aren't very expensive, or the COW operations are somehow synchronising? Copy-on-Write requires some metadata and processing overhead compared to just-plain copying, which obviously makes it slower. It's a time vs. space optimization. -- Brane -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: Incidence of criss-cross merges
Stefan Fuhrmann wrote: On Thu, Jul 12, 2012 at 3:43 PM, Julian Foad wrote: Stefan Fuhrmann wrote: From a process perspective, it seems much more prudent to do qualified merges like merge from /trunk up to the last fully tested nightly build revision and merge from branch up to the point that I think is safe. Yes, that makes sense. [...] A = /trunk Tested versions * * A o---o---o---o---o---o---o---o---o---o---o---o---o \ \ / \ \ __/ \ / \ B o---o---o---o---o---o---o---o---o---o---o Safe versions * * 1 2 3 Sequence of events: 1. Nightly testing. 2. Catch up branch from latest stable trunk. 3. Reintegrate branch to trunk, from latest tested version of branch. That sort of scenario? Exactly. The thing is that at this point the graph does not even depend on whether the changes to a given node actually produce a conflict. If the history processing code had any problems with this kind of merge graph, that problem would surface more often than actual conflicts. Let's first clarify for other readers that we're not concerned with how the two criss-crossing merges themselves work: each of those is a straightforward merge and the fact that they cross over is not relevant to either of them. We might want to build some sort of system for detecting this criss-crossing as it happens, with the aim of alerting the user or preventing the second merge from being committed, but that is not what we are talking about here. Rather, we assume those two criss-crossing merges have already happened, and we are talking now about how a third merge (afterwards) will behave. Currently, the symmetric merge code treats a criss-cross merge by choosing the later of the two possible common ancestors. In fact, this is just a fall-out from choosing the youngest common ancestor: it doesn't currently fetch enough information to notice that the latest merges in each direction cross over. The result of choosing one of the common ancestors will be a sub-optimal merge. Typically, all needed changes are merged, but some unneeded changes are merged too (changes that had already been made in the target branch, either originally or through an earlier merge). Therefore the merge will, in general, have spurious conflicts due to making the same change again. In simple cases the duplicate changes may be auto-resolved: in particular, Subversion's internal text merge auto-resolves duplicate hunks of text added to a file, and Subversion auto-resolves duplicate added properties, but that is only going to happen when such additions were clean additions. There may be other ways in which the result is sub-optimal, such as failing to report a conflict and just choosing one of the alternatives, where the user really should have been given a conflict to resolve. Note also that sub-optimal doesn't necessarily mean just a bit worse that ideal, it can mean unusably bad in some cases. It so happens that in trying to make automated test scenarios for all possible merges [1], I am running in to the issue of criss-cross merges. In preparation for attempting a merge from A to B after a scenario such as this one: A1 A2 ---o---x---o-- mergeinfo = B:1 / / \ \ / \ ---o---o---x-- mergeinfo = A:1-2 B1 B2 my latest attempt to fake the scenario does this: A1 A2 AF where AF makes changes B1 ---o---o---o-- and sets mergeinfo = B:1 / \ ---o---o---o-- where BF makes change A1,A2 B1 B2 BF and sets mergeinfo = A:1-2 but I have just realized (after seeing unexpected conflicts in the following merge) that that actually represents a criss-cross merge: A1 A2 ---o---o---x-- mergeinfo = B:1-2 / __\ _/ \ / \ ---o---o---x-- mergeinfo = A:1 B1 B2 The end points (the tips of the two branches) are in the same state as what I was trying to achieve (the first diagram), but the difference is that the state labaled as 'A2' does not have change 'B1' in it in this second case. The merge code will use that state as the 'base' of the three-way merge, and thus the result it produces will be different from the result produced by a merge after the scenario set up in the first diagram. The state of A2 is the only relevant difference between the non-criss-cross (first diagram) and criss-cross (third diagram) scenarios; the mergeinfo on A2 will also differ and the states and mergeinfo of some other nodes may also differ, but those other differences are not noticed by the current algorithms (symmetric and 1.7 non-reintegrate, that is; 1.7 reintegrate would look at different nodes). As far as I have been able to discover, there is no generally agreed solution to the problem.
