RE: xdelta, svndiff, zlib, or some other problem
> I went into subversion/svn, and I edited every single .c file. I put a > fprintf(stderr,"function name\n"); into every function, just to show > me where svn is going after it's initiated. There are a lot of files, > and there are a lot of functions within those files. Start svn in gdb, set a few breakpoints and print a stack trace. - Winston _ Hotmail: Trusted email with powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969
xdelta, svndiff, zlib, or some other problem
I'll repost with more specifics once I have them, but for now, I'm just asking for advice on how to get better specifics. There is some sort of problem, where sometimes, a commit or other operation which should take ~10sec instead requires ~15min. It is reproducible, but it depends on the data being committed, and currently the data being committed is private, so I can't demonstrate the problem to the outside world. I tried reproducing the problem using random data, but it didn't happen. I tried introducing some structure to the random data, but it still didn't happen. The data in question is ~45M data files. I have several different versions of the same file, as generated by engineers who reported the problem. In an attempt to better understand the data structure inside the files, I did a rolling md5, of every 1M chunk of the file, and then diff'd the md5's and found that approx 1 in 20 of the 1M chunks match from version to version, so from version to version, some large sections of the file have changed, but it's not all changed. Also, I didn't do any larger or smaller granularity than 1M chunks, so it's possible that even within a specific 1M section of the file, the data might be unchanged, or just reordered, or shifted or something like that ... When I gzip the files, they compress to approx 20% of their original size, which means there's plenty of repeated patterns within the file, even within the 1M chunks that have changed from rev to rev. In order to reproduce the problem, I make a new repo, I do a checkout via file:///, I copy rev 1 of some file to the WC, I do an add and commit. It completes in 11sec. I then overwrite it with rev2, commit, overwrite with rev3, etc. After around rev10 or so, suddenly the commit takes 15minutes instead of 10sec. I destroy my repo and WC and start all over again. When it happens, I kill -KILL svn, do a svn cleanup, and attempt the commit again. Once the problem situation is encountered, it doesn't go away until after a successfully completed commit. As long as I interrupt my commit (and do a cleanup), even if I overwrite the file with various other new versions and attempt the commit, this particular rev is always stuck as a "15min" rev. In order to get a better understanding of precisely what is the problem, (and precisely what svn is doing during that time) ... svn is 100% cpu bound. So I have taken the following strategy: (This is where the question is.) I am asking you guys if there's any debug mode for svn, or any better way to debug. I went into subversion/svn, and I edited every single .c file. I put a fprintf(stderr,"function name\n"); into every function, just to show me where svn is going after it's initiated. There are a lot of files, and there are a lot of functions within those files. The flow of the program is far from straightforward. So far, I've put in a lot of effort, but I don't have any result. It's bed time. Tomorrow, unless somebody here offers me any better advice, I plan to continue sprinkling printf()'s into the svn source code, until I can find what functions or sections the process is spending all of its compute cycles in. People have suggested this is going to be xdelta. Probably it is. But it's not yet proven. Thanks for any tips...
Re: auto-upgrade of working copy
On Thu, Jul 01, 2010 at 05:00:13PM -0400, Greg Stein wrote:
> Yup. I have dozens of working copies. The auto-upgrade is an awesome
> and useful feature. I don't have to worry about the fact that
> Subversion has changed something in its metadata. Why the heck should
> I care?
>
> The manual upgrade process is the odd-man-out here. As I mentioned
> earlier, we decided on that with *reluctance* because of the manual
> intervention that it will impose upon people. That we are monkeying
> with something so strongly, that we couldn't make it invisible to the
> user.
>
> "Easy" should be the prevailing case, and that means auto-upgrade.
>
Fair enough, we can default to auto-upgrade.
> Config options? Bleah. I dislike increasing the conceptual burden on
> our users ("hunh? should I set this? what is the impact? why do I need
> it? is this a good idea? am I gonna break something?").
Let's at least provide a config flag to disable it so users who really
don't want it can turn it off. If turned off, we provide an informative
prompt that asks the user if proceeding with the upgrade is fine and
warns about implications with multi-client use.
Then, when the day of server-side configuration finally comes, admins
can turn auto-upgrade off for all their users if they know that users will
(maybe just temporarily) be using multiple clients in incompatible versions.
I think this would make things a lot easier for users in environments
where tortoise, cli clients and various eclipse plugins all touch the
same working copies.
For this group of users, auto-upgrade is really annoying, especially
if people managing the client installations don't upgrade all svn clients
consistently.
Actually, the problem is not so much in the upgrade itself (people
eventually realise what happened and get new WCs), but poor user
interfaces.
E.g. eclipse simply 'disconnects' unreadable working copies.
They're just gone. They disappear from the workspace after a CLI client
or tortoise upgraded them. This is highly confusing, so if we required
all svn clients using 1.7 and above to pass in a callback for prompting
users about the upgrade if the config says to do so, the user will at
least have been prompted and will know what has happened.
This make most sense with server-side configuration of course.
But that's already on the long-term road map.
Stefan
Re: svn commit: r959257 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
On Thu, Jul 1, 2010 at 11:41, Philip Martin wrote: > Greg Stein writes: > >> Dood. Re-read my email. I said interim wq items do not have to be supported. >> Only 1.7 [release] items. > > So when do we autoupgrade? > > 1.7-dev to 1.7-dev > > I disabled the autoupgrade with a workqueue as it might > break. Developers have to run cleanup with an older client. I'm not > quite sure if you object to this or not. It would be nice to auto-upgrade, but sure... devs can deal with this pain. Not worried here. It would be even nicer to fail only if *certain* items are discovered, rather than "any" item. > 1.7-dev to 1.7.x > > When 1.7.x is released the problems with old 1.7-dev workqueues still > exist, so it doesn't seem sensible to suddenly enable autoupgrade > unconditionally. Developers will probably still have to run cleanup > with an older client. Same as above. > 1.7.x to 1.7.x > > The format doesn't change during a release, so we don't have to > autoupgrade. Right. > 1.7-dev to 1.8-dev > > The 1.7-dev workqueue problems haven't gone away, and we are still > dealing with developer working copies. Right. Same as before. "1.7-dev with wq... would be nice to auto-upgrade, but failing is okay". > 1.7.x to 1.8-dev > > Here we could autoupgrade if we can exclude problem 1.7-dev > workqueues. I suppose we could scan the workqueue, or perhaps we could > bump the format shortly before 1.7.x and autoupgrade from that version > onwards. This is the case that I'm concerned about, and tried to clarify in my earlier email. Once 1.7 is released, then auto-upgrades may need to inspect/rewrite the workqueue. Hopefully, they can ignore it (much like we ignored stale "log" files during previous auto-upgrades). We can do format bumps or rename workqueue OP_* values to separate -dev from -release items. Cheers, -g
Re: auto-upgrade of working copy
Yup. I have dozens of working copies. The auto-upgrade is an awesome
and useful feature. I don't have to worry about the fact that
Subversion has changed something in its metadata. Why the heck should
I care?
The manual upgrade process is the odd-man-out here. As I mentioned
earlier, we decided on that with *reluctance* because of the manual
intervention that it will impose upon people. That we are monkeying
with something so strongly, that we couldn't make it invisible to the
user.
"Easy" should be the prevailing case, and that means auto-upgrade.
Config options? Bleah. I dislike increasing the conceptual burden on
our users ("hunh? should I set this? what is the impact? why do I need
it? is this a good idea? am I gonna break something?").
Cheers,
-g
On Thu, Jul 1, 2010 at 11:20, Bob Jenkins wrote:
> I think the question you'd get a better response on would be do they use
> multiple clients on a single working copy. That's really the only
> scenario where they are likely to not want to upgrade the working copy.
> Not to say there aren't other edge cases, but this change would seem to
> mainly play to this group. The others are just having to take an action
> they want 90+% of the time.
>
> Bob Jenkins
>
> -Original Message-
> From: Bob Archer [mailto:bob.arc...@amsi.com]
> Sent: Thursday, July 01, 2010 10:48 AM
> To: Mark Phippard; dev@subversion.apache.org
> Subject: RE: auto-upgrade of working copy
>
> tortoise is a GUI and it could present a simple "Ok to upgrade your
> working copy" dialog.
>
> Perhaps an email on the user list to do an informal poll?
>
> BOb
>
>
Re: Enable SVN_EXPERIMENTAL_PRISTINE and WC-format 17
Do we have tests for the upgrade process? For example, upgrading text-bases from a 1.0 working copy (no revert-base!), from 1.4 working copies when revert was introduced, etc. Tests for computing missing checksums? (that's the one thing stopping my in-db-props format bump) On Thu, Jul 1, 2010 at 12:23, Julian Foad wrote: > Any objections to enabling SVN_EXPERIMENTAL_PRISTINE and WC format = 17 > in trunk tomorrow morning? > > Since r959358, builds with SVN_EXPERIMENTAL_PRISTINE defined and WC > format bumped to 17 are passing all tests in the test suite and I have > been using such a build on one of my trunk WCs today. > > What's not there yet? > > - removing unreferenced pristines from the store > > That's the main thing. That means the pristine store directory (and DB > table) will grow with each "svn update". I think that's OK to work with > during development for a short while. I'm starting to write some > cleanup code now. > > I'm looking forward to removing a lot of cruft after we enable it. > > - Julian > > >
Re: svn commit: r958583 - /subversion/trunk/subversion/tests/svn_test_main.c
On Thu, Jul 1, 2010 at 09:20, Julian Foad wrote: >... > I think the root of the problem is the C test harness code runs the code > under test in-process. Therefore if code-under-test crashes, test suite > fails to report results. The correct fix would be: test harness runs > code-under-test in a subprocess and catches any crashes. Yup. Of course, that could mean that sub-tests 7..10 are not run, but the harness might even be able to restart the test and avoid the crashing test. More work than I think we care to do :-P ... especially given your solution below. > The change I made is to make the harness less likely to bomb out, more > likely to report test results, when there's (a specific kind of) > undefined behaviour in the code under test. However, there are two use > cases: (1) a full test run with reporting; (2) running the test in a > debugger order to debug it. I was helping (1); sounds like (2) is your > concern. Yes. > To accommodate both (1) and (2) without rewriting the harness to run a > sub-process, I think the catch-assertion-failures should be enabled when > run within the (greater) test suite, and disabled when being run as an > individual executable (such as in your debugger). > > Rationale for catching and rporting assertion failures in the code under > test is that such failures do happen during development, just like any > test failures, and there's no special reason why the developer who runs > into such a failure should have to go and fix it before he is able to > perform a full test suite run. > > >> The testing code should use SVN_TEST_ASSERT() or >> SVN_TEST_STRING_ASSERT(). These "assertions" will do the right thing, >> rather than dumping core. (Stefan was using normal assertions in his >> test code, which was the incorrect part) > > I agree with that. My change was not intended to allow the use of > normal assertions in the test suite, but only to catch assertion > failures deep within the code under test. Okee doke. That's fair! > I'll see if I can enable the trap via a flag passed in by the test > suite, and disable it by default, so it works as before in your > running-under-GDB scenario. Would that work for you? It sure does, and I reviewed the changes. Looks great... thanks!! Cheers, -g
Re: svn commit: r958630 - in /subversion/trunk/subversion: libsvn_ra_local/split_url.c tests/libsvn_ra_local/ra-local-test.c
On Thu, Jul 1, 2010 at 09:47, Julian Foad wrote: >... > That is fine for now but, if we think about possible futures, this is > not necessarily the way it has to be. > > When an API definition says (or implies) that a valid URL is required, > this means (or implies) that an invalid URL argument leads to undefined > behaviour. That is, if an application passes such an argument to the > API, it cannot expect a good result for any definition of "good", nor > can it expect that the library will throw an assertion failure, or > crash, or rely on any kinds of behaviour whatsoever. We already know > this. > > We define our own development and testing strategy. We *could* decide > that our APIs will catch certain groups of invalid inputs in a certain > way (at least in debug builds), and we *could* decide that we will have > tests that ensure we have remembered to catch those invalid inputs in > that way. That would be a valid engineering practice, and if we did > then the test suite by definition *would* be allowed to pass "invalid" > arguments. (The non-URL argument would be classed as "invalid" with > respect to the API promises that apply to regular API users, but as a > "valid" test case within the confines of our chosen testing practices.) > > However, we haven't decided to do our development that way. Therefore I > removed the part of the test where it expected the undefined behaviour > to be a particular behaviour. Agreed on all parts! Yes, one day we could define the expectation, then test for that. But that will be another huge batch of work :-P Cheers, -g
Re: auto-upgrade of working copy
Mark Phippard wrote on Thu, 1 Jul 2010 at 13:45 -0400: > Due to the way TSVN is integrated into Windows you can only have one > version installed. So this scenario really cannot happen, other than > doing a complete uninstall of 1.6 and reinstalling 1.5. Then let's assume that they either do a complete reinstall as you say, or use some other client. (My point wasn't specific to TSVN.)
Re: auto-upgrade of working copy
On Thu, Jul 1, 2010 at 1:24 PM, Daniel Shahaf wrote: >> I would guess a good percentage of those users, likely the majority, >> use no other SVN client. > > There is the "I have TSVN 1.5 and want to try TSVN 1.6 without > irreversibly breaking all my working copies" scenario. > > (I would guess not everyone who uses TSVN is going to create a test > repository, populate it, and checkout it just in order to play with > a new TSVN version; or maybe they have other reasons for wanting to play > with the new version on their everyday WC) Due to the way TSVN is integrated into Windows you can only have one version installed. So this scenario really cannot happen, other than doing a complete uninstall of 1.6 and reinstalling 1.5. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: auto-upgrade of working copy
Mark Phippard wrote on Thu, 1 Jul 2010 at 10:38 -0400: > On Thu, Jul 1, 2010 at 10:33 AM, Stefan Sperling wrote: > > >> We are only ever going to hear the complaints. That does not mean > >> they speak for the majority of users. > > > > Oh, I didn't mean to imply that I'd expect people to write in > > out of the blue, asking for the feature to be kept. > > > > I meant to say that I cannot recall any user ever requesting > > that auto-upgrades be kept during a discussion about whether > > or not auto-upgrades should be happening or not. > > > > Is there anyone? If so, speak up, now is your chance :) > > Well TortoiseSVN, as an example, has been downloaded over 22 million times: > > http://sourceforge.net/top/topalltime.php?type=downloads > > I would guess a good percentage of those users, likely the majority, > use no other SVN client. There is the "I have TSVN 1.5 and want to try TSVN 1.6 without irreversibly breaking all my working copies" scenario. Daniel (I would guess not everyone who uses TSVN is going to create a test repository, populate it, and checkout it just in order to play with a new TSVN version; or maybe they have other reasons for wanting to play with the new version on their everyday WC)
Pristine store - deletion / clean-up
I see two things we should do: (1) ensure pristines that become unreferenced are deleted at that time; (2) add pristine store garbage collection (GC). In r959723 I make "svn cleanup" remove all unreferenced pristines, as an easy start to (2), mainly just as a useful option to use during development before the pristine store looks after itself properly. (1) is the important one, the way I see it. The important bit not being actually deleting it, but rather ensuring that every time one becomes unreferenced, we invoke a pristine store API that *has the option of* removing it. (Later, we may want to configure the store so that this API doesn't actually remove unused texts until some time after it has become unreferenced, depending on cache fullness etc.) (2) can be just an "svn cleanup" action for now; it's only if we later want to start hanging on to unreferenced texts as described above that we will start needing GC to happen automatically. Or if we fail to fully implement (1) of course. - Julian
Enable SVN_EXPERIMENTAL_PRISTINE and WC-format 17
Any objections to enabling SVN_EXPERIMENTAL_PRISTINE and WC format = 17 in trunk tomorrow morning? Since r959358, builds with SVN_EXPERIMENTAL_PRISTINE defined and WC format bumped to 17 are passing all tests in the test suite and I have been using such a build on one of my trunk WCs today. What's not there yet? - removing unreferenced pristines from the store That's the main thing. That means the pristine store directory (and DB table) will grow with each "svn update". I think that's OK to work with during development for a short while. I'm starting to write some cleanup code now. I'm looking forward to removing a lot of cruft after we enable it. - Julian
Re: Antwort: Re: ... Re: dangerous implementation of rep-sharing cache for fsfs
On Thu, 2010-07-01 at 08:56 -0400, michael.fe...@evonik.com wrote: > I better already start to run for it, > when I ever approve the use of the current implementation of the > representation cache. Here's what this says to me: it doesn't matter what the real risks are; it only matters that the quantifiable mathematical risks I know about be reduced to 0, regardless of the cost. That's sometimes a rational attitude to take in the world of legalities and politics. In the world of engineering, it's not popular, which is why hash-indexed storage and cryptography are used in a wide variety of applications. It's pointless to reduce the quantifiable risks from 2^-(many) to 0 when we know that the human factors and mechanical risks are much larger.
Re: SVN Apache Installation
[David Swingley] > I am trying to install TortoiseSVN version 1.6.8 and use it on a Unix > server running Apache/2.0.63 (Red Hat). This question is more approriate for us...@subversion.apache.org. The dev list is about development of Subversion itself. That said, I note that in order to build mod_dav_svn and its libraries, you will want to install various development packages that come with your Red Hat system, starting with apr-devel, apr-util-devel, and httpd-devel. I mention those specifically because if you get them from another source, they may not be compatible with your Apache 2.0. Then you probably want to look in the Subversion source distribution under packages/rpm/, where various .spec and supporting files live. Building rpms from .spec files is a bit beyond the present scope. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: svn commit: r959257 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
Greg Stein writes: > Dood. Re-read my email. I said interim wq items do not have to be supported. > Only 1.7 [release] items. So when do we autoupgrade? 1.7-dev to 1.7-dev I disabled the autoupgrade with a workqueue as it might break. Developers have to run cleanup with an older client. I'm not quite sure if you object to this or not. 1.7-dev to 1.7.x When 1.7.x is released the problems with old 1.7-dev workqueues still exist, so it doesn't seem sensible to suddenly enable autoupgrade unconditionally. Developers will probably still have to run cleanup with an older client. 1.7.x to 1.7.x The format doesn't change during a release, so we don't have to autoupgrade. 1.7-dev to 1.8-dev The 1.7-dev workqueue problems haven't gone away, and we are still dealing with developer working copies. 1.7.x to 1.8-dev Here we could autoupgrade if we can exclude problem 1.7-dev workqueues. I suppose we could scan the workqueue, or perhaps we could bump the format shortly before 1.7.x and autoupgrade from that version onwards. -- Philip
RE: auto-upgrade of working copy
I think the question you'd get a better response on would be do they use multiple clients on a single working copy. That's really the only scenario where they are likely to not want to upgrade the working copy. Not to say there aren't other edge cases, but this change would seem to mainly play to this group. The others are just having to take an action they want 90+% of the time. Bob Jenkins -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Thursday, July 01, 2010 10:48 AM To: Mark Phippard; dev@subversion.apache.org Subject: RE: auto-upgrade of working copy tortoise is a GUI and it could present a simple "Ok to upgrade your working copy" dialog. Perhaps an email on the user list to do an informal poll? BOb
RE: auto-upgrade of working copy
> Most users don't like doing something more and most don't use > multiple > clients on a single working copy which is really where the > automation > bites you. That said, I wouldn't argue that making this change I agree with that. However, it isn't often that you will be upgrading from 1.x to 1.y ... so it will be something you have to do 1 time a YEAR maybe. How long has 1.6 been out? BOb
SVN Apache Installation
I am trying to install TortoiseSVN version 1.6.8 and use it on a Unix server running Apache/2.0.63 (Red Hat). Can someone please enlighten me on where to get these two packages, and how to install them? LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so Thanks, David
Re: Antwort: Re: ... Re: dangerous implementation of rep-sharing cache for fsfs
Mark Mielke wrote on Thu, 1 Jul 2010 at 10:40 -0400: > I read that article several years ago. Correct me if I am wrong - but the > article does not describe a "real world collision". It describes how it is > technically possible to find a collision in fewer than previous thought > sample. Yeah. And in general, these results have a tendency of using "2**n time and space"... (don't know if this one too; haven't studied the details) Fortunately hard disks of 2**70 bytes are still scarce :) > Where "find" does not mean real world document. It's still theoretical > that a real life a.c will collide with a real life z.jpg in the same > repository. On a tangent... what's the state of the art in finding almost-collisions? e.g., to find two datas whose sha1's agree on X bits? (X < 160)
Re: auto-upgrade of working copy
I definitely think people do like having this automatically done for them with the only exception being those people who use multiple clients on a single working copy. I'm not surprised no one talks about it as a desirable feature as it is just how it has always worked. As Mark notes, you'll hear more about it when they now have to take an explicit step. I think you'll definitely hear about it then just because it is a change and requires action when people crave automation. Most users don't like doing something more and most don't use multiple clients on a single working copy which is really where the automation bites you. That said, I wouldn't argue that making this change isn't for the best and people will adjust. Bob -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Thursday, July 01, 2010 10:34 AM Oh, I didn't mean to imply that I'd expect people to write in out of the blue, asking for the feature to be kept. I meant to say that I cannot recall any user ever requesting that auto-upgrades be kept during a discussion about whether or not auto-upgrades should be happening or not. Is there anyone? If so, speak up, now is your chance :) Stefan
RE: auto-upgrade of working copy
> >> We are only ever going to hear the complaints. That does not > mean > >> they speak for the majority of users. > > > > Oh, I didn't mean to imply that I'd expect people to write in > > out of the blue, asking for the feature to be kept. > > > > I meant to say that I cannot recall any user ever requesting > > that auto-upgrades be kept during a discussion about whether > > or not auto-upgrades should be happening or not. > > > > Is there anyone? If so, speak up, now is your chance :) > > Well TortoiseSVN, as an example, has been downloaded over 22 > million times: > > http://sourceforge.net/top/topalltime.php?type=downloads > > I would guess a good percentage of those users, likely the > majority, > use no other SVN client. In the Eclipse world we certainly have a > decent number of users that do not know what a command line is or > use > any other client (probably not a majority of users though). > > I think anyone that basically just uses one client enjoys the fact > that they do not have to think about this aspect of Subversion. We > will soon enough learn if having to take a specific upgrade step > introduces any usability problems for these users. > > As I said though, I still think the explicit upgrade makes sense. > It > might cause some pain though. > tortoise is a GUI and it could present a simple "Ok to upgrade your working copy" dialog. Perhaps an email on the user list to do an informal poll? BOb
Re: svn commit: r958583 - /subversion/trunk/subversion/tests/svn_test_main.c
I (Julian Foad) wrote: > I'll see if I can enable the trap via a flag passed in by the test > suite, and disable it by default, so it works as before in your > running-under-GDB scenario. Would that work for you? r959683. - Julian
Re: Antwort: Re: ... Re: dangerous implementation of rep-sharing cache for fsfs
On 07/01/2010 08:00 AM, michael.fe...@evonik.com wrote: Thanks for your wishes, but it seems that I will never be famous: "Hash Function Update Due to Potential Weakness Found in SHA-1" http://www.rsa.com/rsalabs/node.asp?id=2834 I read that article several years ago. Correct me if I am wrong - but the article does not describe a "real world collision". It describes how it is technically possible to find a collision in fewer than previous thought sample. Where "find" does not mean real world document. It's still theoretical that a real life a.c will collide with a real life z.jpg in the same repository. If real life examples start to crop up - we know things absolutely need to be fixed. As long as things stay in the realm of theory and manipulated scenarios - the situation is quite different. It's similar to the technical potential for failure in RAM and hard disks. But, we choose to use these for some reason... Cheers, mark -- Mark Mielke
Re: auto-upgrade of working copy
On Thu, Jul 1, 2010 at 10:33 AM, Stefan Sperling wrote: >> We are only ever going to hear the complaints. That does not mean >> they speak for the majority of users. > > Oh, I didn't mean to imply that I'd expect people to write in > out of the blue, asking for the feature to be kept. > > I meant to say that I cannot recall any user ever requesting > that auto-upgrades be kept during a discussion about whether > or not auto-upgrades should be happening or not. > > Is there anyone? If so, speak up, now is your chance :) Well TortoiseSVN, as an example, has been downloaded over 22 million times: http://sourceforge.net/top/topalltime.php?type=downloads I would guess a good percentage of those users, likely the majority, use no other SVN client. In the Eclipse world we certainly have a decent number of users that do not know what a command line is or use any other client (probably not a majority of users though). I think anyone that basically just uses one client enjoys the fact that they do not have to think about this aspect of Subversion. We will soon enough learn if having to take a specific upgrade step introduces any usability problems for these users. As I said though, I still think the explicit upgrade makes sense. It might cause some pain though. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: auto-upgrade of working copy
On Thu, Jul 01, 2010 at 10:19:08AM -0400, Mark Phippard wrote: > On Thu, Jul 1, 2010 at 5:33 AM, Stefan Sperling wrote: > >> 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". > > > > I have repeatedly heard similar complaints and would therefore prefer > > an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working copies > > starting with 1.7. And I have never heard anyone asking for the auto-upgrade > > feature to be kept. > > I am not against having an svn upgrade, but it seems worth noting why > would anyone bother to report that they want you to keep a feature > they already have? If users are happy with auto-upgraded working > copies, which is all we ever gave them, why would they feel the need > to post requests to keep the feature? > > We are only ever going to hear the complaints. That does not mean > they speak for the majority of users. Oh, I didn't mean to imply that I'd expect people to write in out of the blue, asking for the feature to be kept. I meant to say that I cannot recall any user ever requesting that auto-upgrades be kept during a discussion about whether or not auto-upgrades should be happening or not. Is there anyone? If so, speak up, now is your chance :) Stefan
Re: auto-upgrade of working copy
On Thu, Jul 1, 2010 at 5:33 AM, Stefan Sperling wrote: >> 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". > > I have repeatedly heard similar complaints and would therefore prefer > an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working copies > starting with 1.7. And I have never heard anyone asking for the auto-upgrade > feature to be kept. I am not against having an svn upgrade, but it seems worth noting why would anyone bother to report that they want you to keep a feature they already have? If users are happy with auto-upgraded working copies, which is all we ever gave them, why would they feel the need to post requests to keep the feature? We are only ever going to hear the complaints. That does not mean they speak for the majority of users. -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: auto-upgrade of working copy
> I have repeatedly heard similar complaints and would therefore > prefer > an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working > copies > starting with 1.7. And I have never heard anyone asking for the > auto-upgrade > feature to be kept. > > The CLI client can print an error. GUI clients can show a window > prompting > the user whether to run an upgrade or bail out. > > This does not harm people using a single client much, but helps > users > who use several clients simultaneously a lot (they don't have to > get > fresh WCs to continue getting work done). > > We could also add a configuration option to ~/.subversion/config > that > causes working copies to always be auto-upgraded, defaulting to > 'off'. > I know this isn't a democracy, but if you are looking for votes this does seem like a more reasonable way to handle it. Especially in keeping with the goal of "not changing your data unless you tell it to" meme. BOb
Re: svn commit: r958630 - in /subversion/trunk/subversion: libsvn_ra_local/split_url.c tests/libsvn_ra_local/ra-local-test.c
On Mon, 2010-06-28, Greg Stein wrote:
> This is just compounding the problem.
OK, yes, this was wrong. In r959648 I removed this part of this test
(the part where it passes an invalid URL "file:/path/to/repos"). The
test no longer expects an assertion failure.
> The test suite should NEVER cause an assertion. You simply are not
> allowed to pass those arguments into the functions. That is why the
> assertion is there. Neither the test suite, nor third parties should
> pass those bad arguments. Period.
That is fine for now but, if we think about possible futures, this is
not necessarily the way it has to be.
When an API definition says (or implies) that a valid URL is required,
this means (or implies) that an invalid URL argument leads to undefined
behaviour. That is, if an application passes such an argument to the
API, it cannot expect a good result for any definition of "good", nor
can it expect that the library will throw an assertion failure, or
crash, or rely on any kinds of behaviour whatsoever. We already know
this.
We define our own development and testing strategy. We *could* decide
that our APIs will catch certain groups of invalid inputs in a certain
way (at least in debug builds), and we *could* decide that we will have
tests that ensure we have remembered to catch those invalid inputs in
that way. That would be a valid engineering practice, and if we did
then the test suite by definition *would* be allowed to pass "invalid"
arguments. (The non-URL argument would be classed as "invalid" with
respect to the API promises that apply to regular API users, but as a
"valid" test case within the confines of our chosen testing practices.)
However, we haven't decided to do our development that way. Therefore I
removed the part of the test where it expected the undefined behaviour
to be a particular behaviour.
- Julian
> If you want to convert the assertions into checked failures, and
> return an error on those failures... fine. But that is different from
> an assertion. The assertion means "you should NOT have done this."
>
> That isn't a testable case. That is flatly a wrong programming construction.
>
> -g
>
> On Mon, Jun 28, 2010 at 12:40, wrote:
> > Author: julianfoad
> > Date: Mon Jun 28 16:40:52 2010
> > New Revision: 958630
> >
> > URL: http://svn.apache.org/viewvc?rev=958630&view=rev
> > Log:
> > Remove some code that was just to help the test suite, now that the test
> > suite can catch SVN_ERR_ASSERT failures (since r958583).
> >
> > * subversion/libsvn_ra_local/split_url.c
> > (svn_ra_local__split_URL): Don't bother checking the URL before calling
> >svn_uri_get_dirent_from_file_url().
> >
> > * subversion/tests/libsvn_ra_local/ra-local-test.c
> > (split_url_syntax): Accept an assertion failure as an alternative to an
> >"illegal URL" error when testing a malformed URL.
> >
> > Modified:
> >subversion/trunk/subversion/libsvn_ra_local/split_url.c
> >subversion/trunk/subversion/tests/libsvn_ra_local/ra-local-test.c
> >
> > Modified: subversion/trunk/subversion/libsvn_ra_local/split_url.c
> > URL:
> > http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra_local/split_url.c?rev=958630&r1=958629&r2=958630&view=diff
> > ==
> > --- subversion/trunk/subversion/libsvn_ra_local/split_url.c (original)
> > +++ subversion/trunk/subversion/libsvn_ra_local/split_url.c Mon Jun 28
> > 16:40:52 2010
> > @@ -40,13 +40,6 @@ svn_ra_local__split_URL(svn_repos_t **re
> > const char *repos_root_dirent;
> > svn_stringbuf_t *urlbuf;
> >
> > - /* Verify that the URL is well-formed (loosely) */
> > - /* First, check for the "file://" prefix, to avoid assertion in tests */
> > - if (strncmp(URL, "file://", 7) != 0)
> > -return svn_error_createf(SVN_ERR_RA_ILLEGAL_URL, NULL,
> > - _("Local URL '%s' does not contain 'file://' "
> > - "prefix"), URL);
> > -
> > SVN_ERR(svn_uri_get_dirent_from_file_url(&repos_dirent, URL, pool));
> >
> > /* Search for a repository in the full path. */
> >
> > Modified: subversion/trunk/subversion/tests/libsvn_ra_local/ra-local-test.c
> > URL:
> > http://svn.apache.org/viewvc/subversion/trunk/subversion/tests/libsvn_ra_local/ra-local-test.c?rev=958630&r1=958629&r2=958630&view=diff
> > ==
> > --- subversion/trunk/subversion/tests/libsvn_ra_local/ra-local-test.c
> > (original)
> > +++ subversion/trunk/subversion/tests/libsvn_ra_local/ra-local-test.c Mon
> > Jun 28 16:40:52 2010
> > @@ -148,7 +148,7 @@ split_url_syntax(apr_pool_t *pool)
> >
> > /* Use only single slash after scheme */
> > apr_err = try_split_url("file:/path/to/repos", pool);
> > - if (apr_err != SVN_ERR_RA_ILLEGAL_URL)
> > + if (apr_err != SVN_ERR_RA_ILLEGAL_URL && apr_err !=
> > SVN_ERR_ASSERTION_FAIL)
> > return svn_error_create
> >
Re: svn commit: r959090 - in /subversion/trunk/subversion/tests/manual: ./ README permutations.py tree-conflicts-add-vs-add.py
On 2010-06-30 08:53, Daniel Shahaf wrote:
> ne...@apache.org wrote on Tue, 29 Jun 2010 at 23:22 -:
>> + p = Permutations(('A', 'B'), (1, 2, 3), ('-',), (x, y))
>> + print "All items:"
>> + while p.next():
>> +print p.row
>
> Does this duplicate the functionality of itertools.product()?
>
> http://docs.python.org/library/itertools.html?highlight=cartesian
indeed. I asked #python cause it's a bit hard to understand the itertools
help page. And it seems product() does exactly what I want.
list( itertools.product( (1,2), (a,b,c), (x,y) ) )
thanks!
~Neels
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r958583 - /subversion/trunk/subversion/tests/svn_test_main.c
On Mon, 2010-06-28 at 14:40 -0400, Greg Stein wrote: > On Mon, Jun 28, 2010 at 10:09, wrote: > > Author: julianfoad > > Date: Mon Jun 28 14:09:33 2010 > > New Revision: 958583 > > > > URL: http://svn.apache.org/viewvc?rev=958583&view=rev > > Log: > > * subversion/tests/svn_test_main.c > > (main): Configure the Subversion library to raise an error on assertion > >failure, so we can catch it and report a test failure instead of > >aborting the test run. > > No. > > I said the same thing to Stefan a while back when he tried to make a > similar change. Those assertions should continue to fail as they > normally do. When I'm testing, I *want* that core dump. I think the root of the problem is the C test harness code runs the code under test in-process. Therefore if code-under-test crashes, test suite fails to report results. The correct fix would be: test harness runs code-under-test in a subprocess and catches any crashes. The change I made is to make the harness less likely to bomb out, more likely to report test results, when there's (a specific kind of) undefined behaviour in the code under test. However, there are two use cases: (1) a full test run with reporting; (2) running the test in a debugger order to debug it. I was helping (1); sounds like (2) is your concern. To accommodate both (1) and (2) without rewriting the harness to run a sub-process, I think the catch-assertion-failures should be enabled when run within the (greater) test suite, and disabled when being run as an individual executable (such as in your debugger). Rationale for catching and rporting assertion failures in the code under test is that such failures do happen during development, just like any test failures, and there's no special reason why the developer who runs into such a failure should have to go and fix it before he is able to perform a full test suite run. > The testing code should use SVN_TEST_ASSERT() or > SVN_TEST_STRING_ASSERT(). These "assertions" will do the right thing, > rather than dumping core. (Stefan was using normal assertions in his > test code, which was the incorrect part) I agree with that. My change was not intended to allow the use of normal assertions in the test suite, but only to catch assertion failures deep within the code under test. I'll see if I can enable the trap via a flag passed in by the test suite, and disable it by default, so it works as before in your running-under-GDB scenario. Would that work for you? - Julian
Antwort: Re: ... Re: dangerous implementation of rep-sharing cache for fsfs
Hello, Our public relations department will be glad to hear that the web site was of use. ;-) "Well, I quickly checked their website; they're in the pharma business: the business of determining the chances of dying of a pill when you consume it. That definitely explains the paranoia: they're storing law suit evidence in Subversion before it's actually evidence. (Hence the paranoia about the data staying *exactly* what they put in.)" YES, that is exactly the our point. It?s totally uninteresting to anybody how unlikely it was that we lost the evidence that could have shown that the product had been produced with the right ingredients. I better already start to run for it, when I ever approve the use of the current implementation of the representation cache. I?m glad that I found the description of the representation cache suspicious and took a look in the source code. Greetings, Michael Felke Telefon +49 2151 38-1453 Telefax +49 2151 38-1094 michael.fe...@evonik.com Evonik Stockhausen GmbH Bäkerpfad 25 47805 Krefeld http://www.evonik.com Geschäftsführung: Gunther Wittmer (Sprecher), Willibrord Lampen Sitz der Gesellschaft: Krefeld Registergericht: Amtsgericht Krefeld; Handelsregister HRB 5791 This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving in any manner. Thank you. Erik Huelsmann 30.06.2010 22:54 An: Daniel Shahaf Kopie: "dev@subversion.apache.org" , michael.fe...@evonik.com Thema: Re: Antwort: Re: ... Re: dangerous implementation of rep-sharing cache for fsfs On Wed, Jun 30, 2010 at 10:13 PM, Daniel Shahaf wrote: > [ trim CC ] > > Mark Mielke wrote on Wed, 30 Jun 2010 at 21:37 -: >> On 06/30/2010 05:57 AM, michael.fe...@evonik.com wrote: >> > P.S. Thanks for the warning; we are not going to use 1.7. > > Did you check what is the probability of dying in a car accident? Well, I quickly checked their website; they're in the pharma business: the business of determining the chances of dying of a pill when you consume it. That definitely explains the paranoia: they're storing law suit evidence in Subversion before it's actually evidence. (Hence the paranoia about the data staying *exactly* what they put in.) >> > At the Moment we are not using 1.6 either, >> > because of the SHA-1 rep-share cache. > > In 1.6, representation sharing can be DISABLED. Bye, Erik.
Antwort: Re: ... Re: dangerous implementation of rep-sharing cache for fsfs
It doesn?t matter if die in a car accident, What matters, is that my work will be reliable and traceable, when it happens. Because it would be hard for them to ask me any questions, wouldn?t it? And, yes I have learned the that representation sharing can be DISABLED, but there is no reason the do all the work without the need. Best regards and no car accident, Michael Felke Telefon +49 2151 38-1453 Telefax +49 2151 38-1094 michael.fe...@evonik.com Evonik Stockhausen GmbH Bäkerpfad 25 47805 Krefeld http://www.evonik.com Geschäftsführung: Gunther Wittmer (Sprecher), Willibrord Lampen Sitz der Gesellschaft: Krefeld Registergericht: Amtsgericht Krefeld; Handelsregister HRB 5791 This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving in any manner. Thank you. Daniel Shahaf 30.06.2010 22:13 An: "dev@subversion.apache.org" Kopie: michael.fe...@evonik.com Thema: Re: Antwort: Re: ... Re: dangerous implementation of rep-sharing cache for fsfs [ trim CC ] Mark Mielke wrote on Wed, 30 Jun 2010 at 21:37 -: > On 06/30/2010 05:57 AM, michael.fe...@evonik.com wrote: > > P.S. Thanks for the warning; we are not going to use 1.7. Did you check what is the probability of dying in a car accident? > > At the Moment we are not using 1.6 either, > > because of the SHA-1 rep-share cache. In 1.6, representation sharing can be DISABLED.
Re: svn commit: r959257 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
Dood. Re-read my email. I said interim wq items do not have to be supported. Only 1.7 [release] items. On Jul 1, 2010 5:08 AM, "Philip Martin" wrote: Greg Stein writes: > On Wed, Jun 30, 2010 at 13:55, Philip Martin >> We allow the >>> upgrade to continue. If there is an impact on work queue items, then >>> they ... For devs it's better not to autoupgrade. Then they can revert to the version that generated the workqueue and use that. If we autoupgrade they have no usable version. > BUT: the need-clean-wq-for-upgrade is NOT true moving forward from 1.7. > >>> Clients are not exp... I don't see the difference. At some point you have to write the code to do it. > The process that I > encoded in the db-opening logic was to support THAT purpose. > >> not code t... But your plan is that at release we should be capable of handling that old workqueue item? This is a workqueue item only ever produced by a dev version. I'd argue that these pre-1.7 dev workqueues don't need to be supported long-term. You realise that the XML parser in log.c would have to be retained, probably including bits that have already been deleted? And that parser would never be used by people upgrading from 1.6, since they have to cleanup first. >> When we upgrade and run the >> workqueue it will probably fail because the .svn/text-base no lo... After we release 1.7 it's different. We can choose to autoupgrade, or we can treat it like 1.6 and say that an upgrade step is required. It's hard to predict the future. If 1.8 uses a totally different backend for the wc then while we would support upgrading from a 1.7 wc we might not support running 1.7 workqueues. >> That's just one example. I don't know exactly which workqueue items >> break. SVN_WC__LOG_CP_A... I'd argue that's unneccesary, it's a maintenance burden we don't need. Is there a regression test? Does it still work? However it's trivial compared to supporting an XML parser that's not otherwise required. > Another approach is to rename the work item in the OP_FOO symbols. > Stale items become obvious w... I still disagree. Having made the decision to introduce an upgrade step for 1.6-to-1.7 we should take full advantage of that. The intermediate pre-1.7 workqueues do not need to be supported. Then we can throw out all the log parsing code. -- Philip
Antwort: Re: ... Re: dangerous implementation of rep-sharing cache for fsfs
Hello Mark, Thanks for your wishes, but it seems that I will never be famous: ?Hash Function Update Due to Potential Weakness Found in SHA-1? http://www.rsa.com/rsalabs/node.asp?id=2834 Greetings Michael Felke Telefon +49 2151 38-1453 Telefax +49 2151 38-1094 michael.fe...@evonik.com Evonik Stockhausen GmbH Bäkerpfad 25 47805 Krefeld http://www.evonik.com Geschäftsführung: Gunther Wittmer (Sprecher), Willibrord Lampen Sitz der Gesellschaft: Krefeld Registergericht: Amtsgericht Krefeld; Handelsregister HRB 5791 This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving in any manner. Thank you. Mark Mielke 30.06.2010 20:37 An: michael.fe...@evonik.com Kopie: "dev@subversion.apache.org" , Daniel Shahaf , ghud...@mit.edu, Mark Phippard , m...@rola.ch Thema: Re: Antwort: Re: ... Re: dangerous implementation of rep-sharing cache for fsfs I think if you could find a real life collision - you might be able to get some sort of award. Good luck. :-) Cheers, mark On 06/30/2010 05:57 AM, michael.fe...@evonik.com wrote: > Hello, > > O.K., it seems there is really a need to discuss the problem of > SHA-1 collisions more deeply. > > ... > But one is missing! > > 4. The set of one kind of data and that of another kind are overlapping > very infrequent, if at all. They could be seen as highly discriminable > and separated parts of the sample set of all possible data. > So SHA-1 hashes will wildly spread on the first set, doing the best > of its job, and also, but independently, spread on the other set as > wide as it?s expected to do. > > What is the result, when two or more sets of hash values, each widely > spread of the same value range, are used together in one fetch index? > > Perhaps, some can see a danger now, too. > > I? am working on a practical demonstration, which everybody could > reproduce with his or her spreadsheet program. > But please be patient, I have other things to do, as well. > > Greetings, > > P.S. Thanks for the warning; we are not going to use 1.7. > At the Moment we are not using 1.6 either, > because of the SHA-1 rep-share cache. > -- Mark Mielke
RE: auto-upgrade of working copy
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: donderdag 1 juli 2010 11:34
> To: Alan Barrett
> Cc: dev@subversion.apache.org
> Subject: Re: auto-upgrade of working copy
>
> On Thu, Jul 01, 2010 at 09:25:33AM +0200, Alan Barrett wrote:
> > On Wed, 30 Jun 2010, Greg Stein wrote:
> > > Nope. Users cannot generally downgrade their client to run a
> cleanup.
> > > Historically, we have always auto-upgraded the working copies, even
> > > with stale logs in them.
> > >
> > > The 1.7 upgrade process is too invasive and time-consuming, so we
> > > decided to have a manual process ('svn upgrade'). But moving
> forward,
> > > the intent is to continue an auto-upgrade mechanism even with stale
> > > workqueues.
> >
> > 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".
>
> I have repeatedly heard similar complaints and would therefore prefer
> an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working copies
> starting with 1.7. And I have never heard anyone asking for the auto-
> upgrade
> feature to be kept.
>
> The CLI client can print an error. GUI clients can show a window
> prompting
> the user whether to run an upgrade or bail out.
Hmm... and how does a client that is build/designed against 1.5, but now
linked against 1.8 handle this?
It doesn't know how to call svn_client_upgrade() as that is only introduced
in 1.7.
Possible fix: Maybe we should also enable upgrading from older variants of
svn_client_cleanup().
Older clients know how to call that function.
> This does not harm people using a single client much, but helps users
> who use several clients simultaneously a lot (they don't have to get
> fresh WCs to continue getting work done).
>
> We could also add a configuration option to ~/.subversion/config that
> causes working copies to always be auto-upgraded, defaulting to 'off'.
And how does libsvn_wc (and especially the deprecated functions that don't
receive a wc_ctx) decide which config file it should use? Not all functions
receive the configuration that is read by svn and then posted in the
svn_client_ctx_t.
Bert
Re: auto-upgrade of working copy
Stefan Sperling wrote on Thu, 1 Jul 2010 at 12:33 -: > This does not harm people using a single client much, but helps users > who use several clients simultaneously a lot (they don't have to get > fresh WCs to continue getting work done). Including devs around the time of WC format bumps. :-)
RE: auto-upgrade of working copy
We haven't done this so far, but there's the option of allowing svn 1.8 to write into 1.7 wc's (thus making 'svn upgrade' an optional-to-run command) --- just as we do on the server (repos) end. Bolstridge, Andrew wrote on Thu, 1 Jul 2010 at 11:23 -: > > -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: auto-upgrade of working copy
On Thu, Jul 01, 2010 at 09:25:33AM +0200, Alan Barrett wrote:
> On Wed, 30 Jun 2010, Greg Stein wrote:
> > Nope. Users cannot generally downgrade their client to run a cleanup.
> > Historically, we have always auto-upgraded the working copies, even
> > with stale logs in them.
> >
> > The 1.7 upgrade process is too invasive and time-consuming, so we
> > decided to have a manual process ('svn upgrade'). But moving forward,
> > the intent is to continue an auto-upgrade mechanism even with stale
> > workqueues.
>
> 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".
I have repeatedly heard similar complaints and would therefore prefer
an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working copies
starting with 1.7. And I have never heard anyone asking for the auto-upgrade
feature to be kept.
The CLI client can print an error. GUI clients can show a window prompting
the user whether to run an upgrade or bail out.
This does not harm people using a single client much, but helps users
who use several clients simultaneously a lot (they don't have to get
fresh WCs to continue getting work done).
We could also add a configuration option to ~/.subversion/config that
causes working copies to always be auto-upgraded, defaulting to 'off'.
Stefan
Re: svn commit: r959257 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
Greg Stein writes:
> On Wed, Jun 30, 2010 at 13:55, Philip Martin
> wrote:
>> Greg Stein writes:
>>
>>> I completely disagree with this.
>>>
>>> Didn't I just get done describing the intent here?
>>
>> You didn't respond to my questions in the last thread.
>
> Gee. I'm sorry. I have a life. I don't have time to respond to
> everything RIGHT NOW. Maybe I needed to think about it? Maybe I'm
> traveling. Maybe I just want to sit back and play Mass Effect 2 for a
> while.
I realise that. You seemed to be accusing me of ignoring you, and I
was pointing out that I didn't ignore you it's just that I don't agree
with you. Sorry if it came across the wrong way.
>>> We allow the
>>> upgrade to continue. If there is an impact on work queue items, then
>>> they must be upgraded, too.
>>
>> We don't generally support running old workqueues with newer code, so
>> why is uprade so different? Take this recent commit:
>>
>> http://svn.apache.org/viewvc?rev=959374&view=rev
>>
>> it removes SVN_WC__LOG_DELETE_LOCK. Every time we remove one of the
>> log actions we effectively broke any workqueue that included them.
>> Nobody has written any code to migrate those workqueues.
>
> Yup. And because that would only affect devs, and when the workqueue
> code throws an error saying "dunno what 'delete-lock' means", then
> that dev has an easy way to fix themselves. It is an obvious failure
> mode.
>
> I don't care about breaking devs. The interim formats before 1.7 is
> released can enforce a cleanup first. But even that is a pain. I'd
> rather just see something fail in an obvious way and let the dev fix
> it up.
For devs it's better not to autoupgrade. Then they can revert to the
version that generated the workqueue and use that. If we autoupgrade
they have no usable version.
> BUT: the need-clean-wq-for-upgrade is NOT true moving forward from 1.7.
>
>>> Clients are not expected to back up to previous revisions and run "svn
>>> cleanup". We ONLY plan to require that for the 1.6 -> 1.7 transition.
From then on, we can/should/will perform an upgrade with a non-empty
>>> work queue. Every single auto-upgrade in the past has operated in this
>>> fashion, and we will continue to do so from 1.7 onwards.
>>>
>>> Please revert. This is contrary to the design that I explained just
>>> yesterday.
>>
>> Why is it so important to support this? It doesn't affect many people
>> but writing the code to upgrade log items is a big effort. And it's
>
> We don't have to upgrade today's workqueue items. We simply have to
> have a policy to upgrade them once 1.7 is released.
I don't see the difference. At some point you have to write the code
to do it.
> The process that I
> encoded in the db-opening logic was to support THAT purpose.
>
>> not code that will get used by anyone other than people running dev
>> code. It will be poorly tested and a maintenance burden. How long do
>> we keep it? How far back in wcng history do we support?
>>
>> Take this workqueue item:
>>
>> 13|(loggy 30 /home/pm/sw/subversion/obj/wc1 68 > dest=".svn/text-base/f.svn-base"
>> name=".svn/svn-ZIxV3z"/>
>> )
>>
>> It will break the working copy on upgrade because the wrong text-base
>> will get copied into the pristine store.
>
> Right. Let it break.
>
> At 1.7 release time, the above style of wq item could be hard to
> upgrade, so we could make it more semantic-based. "install TEMP into
> pristine store as CHECKSUM". That would be much more resilient to
> changes in the working copy format.
But your plan is that at release we should be capable of handling that
old workqueue item? This is a workqueue item only ever produced by a
dev version. I'd argue that these pre-1.7 dev workqueues don't need
to be supported long-term. You realise that the XML parser in log.c
would have to be retained, probably including bits that have already
been deleted? And that parser would never be used by people upgrading
from 1.6, since they have to cleanup first.
>> When we upgrade and run the
>> workqueue it will probably fail because the .svn/text-base no longer
>> exists. How will the user handle that? Isn't it better to get an
>> error saying "cleanup first"?
>
> Nope. Users cannot generally downgrade their client to run a cleanup.
> Historically, we have always auto-upgraded the working copies, even
> with stale logs in them.
>
> The 1.7 upgrade process is too invasive and time-consuming, so we
> decided to have a manual process ('svn upgrade'). But moving forward,
> the intent is to continue an auto-upgrade mechanism even with stale
> workqueues.
After we release 1.7 it's different. We can choose to autoupgrade, or
we can treat it like 1.6 and say that an upgrade step is required.
It's hard to predict the future. If 1.8 uses a totally different
backend for the wc then while we would support upgrading from a 1.7 wc
we might not support running 1.7 workqueues.
>> That's just one example. I don't know exactly which workqueue items
>> break. SVN_WC
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.
auto-upgrade of working copy
On Wed, 30 Jun 2010, Greg Stein wrote:
> Nope. Users cannot generally downgrade their client to run a cleanup.
> Historically, we have always auto-upgraded the working copies, even
> with stale logs in them.
>
> The 1.7 upgrade process is too invasive and time-consuming, so we
> decided to have a manual process ('svn upgrade'). But moving forward,
> the intent is to continue an auto-upgrade mechanism even with stale
> workqueues.
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. This gets even worse when working copies are shared by
multiple users (which happens a lot more often than I would like).
--apb (Alan Barrett)
