Re: svn commit: r1095214 - in /subversion/trunk/subversion/libsvn_wc: upgrade.c wc-metadata.sql wc.h wc_db_pristine.c
Sorry, folks. I'm a guilty party here, too. I got cranky about a prior commit that made bogus assumptions about the state of the database, ultimately annoyin^H^H^H^H^H^H^Hencouraging Bert to make this format bump. On 04/19/2011 05:37 PM, Greg Stein wrote: > Bert: > > I think you should check with the community before doing a format > bump. You're cutting us out of the conversation. > > -g > > On Tue, Apr 19, 2011 at 17:05, wrote: >> Author: rhuijben >> Date: Tue Apr 19 21:05:28 2011 >> New Revision: 1095214 >> >> URL: http://svn.apache.org/viewvc?rev=1095214&view=rev >> Log: >> Bump our working copy format version to 28 and fixup the remaining MD5 >> references in the NODES table to SHA1. (This also fixes the reference counts) >> >> On any working copy checked out in +- the last half year (and probably >> longer) >> this only bumps the working copy format number. >> >> * subversion/libsvn_wc/upgrade.c >> (bump_to_28): New function. >> (svn_wc__upgrade_sdb): Add bump to 28. >> >> * subversion/libsvn_wc/wc-metadata.sql >> (STMT_UPGRADE_TO_28): Add the bump to format 28 query. >> >> * subversion/libsvn_wc/wc.h >> (SVN_WC__VERSION): Document format 28 and switch to 28. >> >> * subversion/libsvn_wc/wc_db_pristine.c >> (svn_wc__db_pristine_read): Revert r1095194, which reverted some parts of >>r1091381. >> >> Modified: >>subversion/trunk/subversion/libsvn_wc/upgrade.c >>subversion/trunk/subversion/libsvn_wc/wc-metadata.sql >>subversion/trunk/subversion/libsvn_wc/wc.h >>subversion/trunk/subversion/libsvn_wc/wc_db_pristine.c >> ... -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: svn commit: r1095130 - in /subversion/trunk/subversion: libsvn_client/client.h libsvn_client/externals.c libsvn_client/switch.c libsvn_client/update.c libsvn_wc/adm_crawler.c tests/cmdline/externa
On Tue, Apr 19, 2011 at 04:46:52PM -, rhuij...@apache.org wrote: > Author: rhuijben > Date: Tue Apr 19 16:46:51 2011 > New Revision: 1095130 > > URL: http://svn.apache.org/viewvc?rev=1095130&view=rev > Log: > Remove the 'apply svn:externals from added files' code we introduced during > the > development of Subversion 1.7.0. > > While nice to have in certain use cases like testing new externals > (see issue #2267), this quick and dirty hack introduses issues like > issue #3351, where externals are not properly removed. > > This patch brings us back to the original behavior of only applying the > svn:externals as defined by the BASE tree (read: of committed nodes). > Which fixes the original automatic (but until recently mostly hidden) > removal of externals on update. > > The removal/relegation of externals was made more visible in r1095122, > by updating the notification code. Hmmm... was removing this feature really necessary? Instead of removing this feature, could you not reimplement the feature in a way that suits your requirements better, e.g. by making these externals disappear properly when they are reverted? I would have appreciated some discussion before this change was made. There are people out there how need this feature for their workflow, which is why I spent time on making this work. It would be nice to have externals on locally added dirs working for 1.7.0. Are you planning on getting this to work in 1.7.0? Given that you simply closed the issue as WONTFIX I guess that's not the case. Regarding your last comment to the issue, I don't care what the book says. If it says that only committed externals definitions can be handled it is probably talking about an implementation defect rather than an unsurmountable problem. All that said, I really appreciate your work on getting externals fixed because it is a very important part of getting 1.7 released. However, reverting code without prior discussion isn't nice.
Re: [PATCH] to help benchmark.py run on windows
On Tue, Apr 19, 2011 at 17:37, Alan Wood wrote: > On 19 Apr 2011 at 13:07, Greg Stein wrote: >> > >> > On Windows, the path returned by mkdtemp() is something like >> > >> > C:\users\billga~1\appdata\local\temp\tmpfoobar >> > >> > with no leading slash, so an extra slash makes the URL valid. >> > >> > The directory path could even have spaces in it, if the user wishes. >> > For a geeky script like this, we don't have to be paranoid. >> >> I reviewed that portion of Alan's patch and omitted, for the reasons >> Neels stated, but I also think the following is valid: >> >> file://C:/users/blah/blah/repos > > Not valid: the code goes off looking for a network machine called 'C:' and > comes back some > time later with an error. > IIRC the text between the 2nd and 3rd slash is a machine name. Alrighty. >> Thus, I left out the introduction of a slash. Are you sure there is >> supposed to be a third slash in there? My impression is that the >> "third slash" is a result of the leading slash of an absolute path in >> Unix. But for Windows, you start with the drive letter (tho you could >> get a slash if you use a remote path). > > I suppose mkdtemp could come back with '\\servername\temp\blah\'. That would > make a real > mess. That may happen is the current drive was invalid, but so much else > would fail that I > can't really get worried about it. hehe... yeah. I just found this: http://en.wikipedia.org/wiki/File_URI_scheme#Examples While Wikipedia is not authoritative, I see no reason to distrust it. I'll go ahead and apply your original suggestion. Thanks! Cheers, -g
Re: [PATCH] to help benchmark.py run on windows
On 19 Apr 2011 at 13:07, Greg Stein wrote: > > > > On Windows, the path returned by mkdtemp() is something like > > > > C:\users\billga~1\appdata\local\temp\tmpfoobar > > > > with no leading slash, so an extra slash makes the URL valid. > > > > The directory path could even have spaces in it, if the user wishes. > > For a geeky script like this, we don't have to be paranoid. > > I reviewed that portion of Alan's patch and omitted, for the reasons > Neels stated, but I also think the following is valid: > > file://C:/users/blah/blah/repos Not valid: the code goes off looking for a network machine called 'C:' and comes back some time later with an error. IIRC the text between the 2nd and 3rd slash is a machine name. > > Thus, I left out the introduction of a slash. Are you sure there is > supposed to be a third slash in there? My impression is that the > "third slash" is a result of the leading slash of an absolute path in > Unix. But for Windows, you start with the drive letter (tho you could > get a slash if you use a remote path). I suppose mkdtemp could come back with '\\servername\temp\blah\'. That would make a real mess. That may happen is the current drive was invalid, but so much else would fail that I can't really get worried about it. > Bert? Any insight here? > > Cheers, > -g Alan Wood Napier New Zealand Phone +64 6 835 4505
Re: svn commit: r1095214 - in /subversion/trunk/subversion/libsvn_wc: upgrade.c wc-metadata.sql wc.h wc_db_pristine.c
Bert: I think you should check with the community before doing a format bump. You're cutting us out of the conversation. -g On Tue, Apr 19, 2011 at 17:05, wrote: > Author: rhuijben > Date: Tue Apr 19 21:05:28 2011 > New Revision: 1095214 > > URL: http://svn.apache.org/viewvc?rev=1095214&view=rev > Log: > Bump our working copy format version to 28 and fixup the remaining MD5 > references in the NODES table to SHA1. (This also fixes the reference counts) > > On any working copy checked out in +- the last half year (and probably longer) > this only bumps the working copy format number. > > * subversion/libsvn_wc/upgrade.c > (bump_to_28): New function. > (svn_wc__upgrade_sdb): Add bump to 28. > > * subversion/libsvn_wc/wc-metadata.sql > (STMT_UPGRADE_TO_28): Add the bump to format 28 query. > > * subversion/libsvn_wc/wc.h > (SVN_WC__VERSION): Document format 28 and switch to 28. > > * subversion/libsvn_wc/wc_db_pristine.c > (svn_wc__db_pristine_read): Revert r1095194, which reverted some parts of > r1091381. > > Modified: > subversion/trunk/subversion/libsvn_wc/upgrade.c > subversion/trunk/subversion/libsvn_wc/wc-metadata.sql > subversion/trunk/subversion/libsvn_wc/wc.h > subversion/trunk/subversion/libsvn_wc/wc_db_pristine.c >...
Re: svn commit: r1095064 - in /subversion/trunk/subversion/libsvn_wc: status.c wc-queries.sql wc_db.c wc_db.h
On Tue, Apr 19, 2011 at 08:40, wrote: > Author: rhuijben > Date: Tue Apr 19 12:40:36 2011 > New Revision: 1095064 > > URL: http://svn.apache.org/viewvc?rev=1095064&view=rev > Log: > Update svn_wc__db_base_info_t and svn_wc__db_info_t to be more similar to > their one path counterparts. Add a few values which are cheap to obtain > and can avoid further database calls. > > * subversion/libsvn_wc/status.c > (read_info): Update conversion to fill more fields. Remove SVN_DBG() call. That comment is for wc_db.c::read_info. You did something else to this function. And assemble_status is not mentioned. >... Cheers, -g
Re: svn commit: r1095130 - in /subversion/trunk/subversion: libsvn_client/client.h libsvn_client/externals.c libsvn_client/switch.c libsvn_client/update.c libsvn_wc/adm_crawler.c tests/cmdline/externa
Did you even run the externals_tests before committing this? Looks like there is a failure there. On Windows. On Tue, Apr 19, 2011 at 12:46, wrote: > Author: rhuijben > Date: Tue Apr 19 16:46:51 2011 > New Revision: 1095130 > > URL: http://svn.apache.org/viewvc?rev=1095130&view=rev > Log: > Remove the 'apply svn:externals from added files' code we introduced during > the > development of Subversion 1.7.0. > > While nice to have in certain use cases like testing new externals > (see issue #2267), this quick and dirty hack introduses issues like > issue #3351, where externals are not properly removed. > > This patch brings us back to the original behavior of only applying the > svn:externals as defined by the BASE tree (read: of committed nodes). > Which fixes the original automatic (but until recently mostly hidden) > removal of externals on update. > > The removal/relegation of externals was made more visible in r1095122, > by updating the notification code. > > * subversion/libsvn_client/client.h > (svn_client__gather_externals_in_locally_added_dirs): Remove function. > > * subversion/libsvn_client/externals.c > (svn_client__gather_externals_in_locally_added_dirs): Remove function. > > * subversion/libsvn_client/switch.c > (switch_internal): Remove walk of the WORKING tree for externals. > > * subversion/libsvn_client/update.c > (update_internal): Remove walk of the WORKING tree for externals. > > * subversion/libsvn_wc/adm_crawler.c > (read_externals_info): Read the BASE properties, not the ACTUAL ones. > (report_revisions_and_depths): Only call read_externals_info when we know > that we have BASE props. > > * subversion/tests/cmdline/externals_tests.py > (modify_and_update_receive_new_external, > switch_relative_external, > relegate_external): Bring back to their old expectations by just > committing the svn:externals change before testing. > > (update_external_on_locally_added_dir, > switch_external_on_locally_added_dir): Remove functions. > > (test_list): Remove functions. > > Modified: > subversion/trunk/subversion/libsvn_client/client.h > subversion/trunk/subversion/libsvn_client/externals.c > subversion/trunk/subversion/libsvn_client/switch.c > subversion/trunk/subversion/libsvn_client/update.c > subversion/trunk/subversion/libsvn_wc/adm_crawler.c > subversion/trunk/subversion/tests/cmdline/externals_tests.py >...
Re: [PATCH] to help benchmark.py run on windows
On Tue, Apr 19, 2011 at 11:07, Stephen Butler wrote: > > On Apr 19, 2011, at 15:32 , Neels Hofmeyr wrote: > >> On Mon, 2011-04-18 at 19:47 -0400, Greg Stein wrote: >>> Applied in r1094816. >>> >>> On Mon, Apr 18, 2011 at 18:44, Greg Stein wrote: On Mon, Apr 18, 2011 at 07:04, Alan Wood wrote: > Hi devs, > I have just been looking at running the benchmarks and have got to the > stage where I can > run it on windows. > > This attached patch fixes three issues with the script: > 1) use of file:// when I'm sure that file:/// is correct from previous > discussions on this list >> >> This particular change is not necessary -- code extract with >> annotations: >> >> base = tempfile.mkdtemp() # base == '/tmp/dir123' >> repos = j(base, 'repos') # repos == '/tmp/dir123/repos' >> file_url = 'file://%s' % repos # file_url == 'file://' + '/tmp/...' >> >> With your change, file_url becomes file:tmp/..., which is still >> valid, but nonsense :) (BTW, the script would not have worked if there >> had been only two slashes.) > > On Windows, the path returned by mkdtemp() is something like > > C:\users\billga~1\appdata\local\temp\tmpfoobar > > with no leading slash, so an extra slash makes the URL valid. > > The directory path could even have spaces in it, if the user wishes. > For a geeky script like this, we don't have to be paranoid. I reviewed that portion of Alan's patch and omitted, for the reasons Neels stated, but I also think the following is valid: file://C:/users/blah/blah/repos Thus, I left out the introduction of a slash. Are you sure there is supposed to be a third slash in there? My impression is that the "third slash" is a result of the leading slash of an absolute path in Unix. But for Windows, you start with the drive letter (tho you could get a slash if you use a remote path). Bert? Any insight here? Cheers, -g
Re: svn commit: r1095028 - in /subversion/trunk/subversion: include/private/svn_sqlite.h libsvn_subr/sqlite.c
On Apr 19, 2011 7:17 AM, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_subr/sqlite.c Tue Apr 19 11:16:39
2011
> @@ -536,6 +536,11 @@ svn_sqlite__column_is_null(svn_sqlite__s
> return sqlite3_column_type(stmt->s3stmt, column) == SQLITE_NULL;
> }
>
> +svn_boolean_t
> +svn_sqlite__column_bytes(svn_sqlite__stmt_t *stmt, int column)
> +{
> + return sqlite3_column_bytes(stmt->s3stmt, column);
> +}
That is not a boolean return.
Re: [PATCH] to help benchmark.py run on windows
On Tue, 2011-04-19 at 17:07 +0200, Stephen Butler wrote:
> On Apr 19, 2011, at 15:32 , Neels Hofmeyr wrote:
>
>
> This attached patch fixes three issues with the script:
> 1) use of file:// when I'm sure that file:/// is correct from previous
> discussions on this list
> >
> > This particular change is not necessary -- code extract with
> > annotations:
> >
> > base = tempfile.mkdtemp() # base == '/tmp/dir123'
> > repos = j(base, 'repos')# repos == '/tmp/dir123/repos'
> > file_url = 'file://%s' % repos # file_url == 'file://' + '/tmp/...'
> >
> > With your change, file_url becomes file:tmp/..., which is still
> > valid, but nonsense :) (BTW, the script would not have worked if there
> > had been only two slashes.)
>
> On Windows, the path returned by mkdtemp() is something like
>
> C:\users\billga~1\appdata\local\temp\tmpfoobar
>
> with no leading slash, so an extra slash makes the URL valid.
gotcha!
Thanks, Steve, I wasn't aware of that. Sorry, Alan, I am hopelessly
unix. Let me paraphrase. Hopefully unix.
So we need a special treatment. Like
file_url = 'file://'
if not base.startswith('/'):
file_url.append('/')
...or leave the four slashes, that's also fine, actually.
~Neels
Re: [PATCH] NODES.dav_cache in wc.db is always set to NULL in serf.
On Apr 19, 2011 12:10 PM, "Hyrum K Wright" wrote: >... > > False. This is a *cache*, meaning, if it is NULL you don't lose any > information, it may just take longer to get that information. If the > cache is NULL, neon will populate it as needed for increased > performance. > > Note that the cache is inherently NULL the first time you use neon > when checking out a working copy, and yet it works. :) The cache is populated during checkout, so ra_neon actually populates it right from the start. If you switch between RA layers, ra_neon will populate it for nodes changed during an update (generally). Cheers, -g
Re: [PATCH] NODES.dav_cache in wc.db is always set to NULL in serf.
I believe that when ra_serf touches a node, the dav_cache will be set to null. wc_db basically enforces that. On Apr 19, 2011 12:11 PM, "C. Michael Pilato" wrote: > ra_serf in trunk, speaking HTTPv2 with the server, doesn't make use of the > dav_cache. But I can see how that might be a problem when switching between > serf and neon, because neon *does* consult the dav cache (which in your > case, I'm guessing, must be stale). > > At a minimum, if ra_serf isn't going to consult the dav cache, it should at > least be sure to invalidate whatever is stored therein so as not to trip up > neon. > > > On 04/19/2011 11:57 AM, Arwin Arni wrote: >> Hi All, >> >> NODES.dav_cache in wc.db is always set to NULL in serf. >> >> Is it intentional? >> >> If not attached patch would fix it. >> >> Why I am concerned? >> >> I was testing one scenario(master-slave setup) which failed becuase of >> NODES.dav_cache being NULL. >> >> Scenario: >> >> I was trying to understand r900797(Commit where subsequent commits(from same >> WC) to the same out-dated proxy(out-dated only after the first commit) was >> made to succeed via ) >> >> For some time I could see it fail with trunk binary later reduced with the >> following cases, >> >> Case 1: >> svn ci -m "first mod" file --config-option servers:global:http-library=neon >> echo "second mod" >> file >> svn ci -m "second mod" file --config-option servers:global:http-library=neon >> >> Case 1 succeeds. >> >> Case 2: >> svn ci -m "first mod" file --config-option servers:global:http-library=serf >> echo "second mod" >> file >> svn ci -m "second mod" file --config-option servers:global:http-library=serf >> >> Case 2 succeeds >> >> Case 3 >> svn ci -m "first mod" file --config-option servers:global:http-library=neon >> echo "second mod" >> file >> svn ci -m "second mod" file --config-option servers:global:http-library=serf >> >> Case 3 succeeds. >> >> Case 4 >> svn ci -m "first mod" file --config-option servers:global:http-library=serf >> echo "second mod" >> file >> svn ci -m "second mod" file --config-option servers:global:http-library=neon >> >> Case 4 *fails* >> >> Case 5 >> svn ci -m "first mod" file --config-option servers:global:http-library=neon >> echo "second mod" >> file >> svn ci -m "second mod" file --config-option servers:global:http-library=serf >> echo "third mod" >> file >> svn ci -m "third mod" file --config-option servers:global:http-library=neon >> >> Case 5 *fails*. >> >> >> Effectively once your working copy is used with serf you can not go back to >> neon for this particular *CASE*. >> >> Regards, >> Arwin Arni > > > -- > C. Michael Pilato > CollabNet <> www.collab.net <> Distributed Development On Demand >
Re: [PATCH] NODES.dav_cache in wc.db is always set to NULL in serf.
ra_serf uses HTTPv2 which does not use the dav_cache. ra_neon has not been upgraded to use the new protocol. When ra_serf talks HTTPv1, it *may* use dav_cache, but we may have just left that out and taken the speed hit (I don't recall) Cheers, -g On Apr 19, 2011 11:58 AM, "Arwin Arni" wrote: > Hi All, > > NODES.dav_cache in wc.db is always set to NULL in serf. > > Is it intentional? > > If not attached patch would fix it. > > Why I am concerned? > > I was testing one scenario(master-slave setup) which failed becuase of > NODES.dav_cache being NULL. > > Scenario: > > I was trying to understand r900797(Commit where subsequent commits(from > same WC) to the same out-dated proxy(out-dated only after the first > commit) was made to succeed via ) > > For some time I could see it fail with trunk binary later reduced with > the following cases, > > Case 1: > svn ci -m "first mod" file --config-option servers:global:http-library=neon > echo "second mod" >> file > svn ci -m "second mod" file --config-option servers:global:http-library=neon > > Case 1 succeeds. > > Case 2: > svn ci -m "first mod" file --config-option servers:global:http-library=serf > echo "second mod" >> file > svn ci -m "second mod" file --config-option servers:global:http-library=serf > > Case 2 succeeds > > Case 3 > svn ci -m "first mod" file --config-option servers:global:http-library=neon > echo "second mod" >> file > svn ci -m "second mod" file --config-option servers:global:http-library=serf > > Case 3 succeeds. > > Case 4 > svn ci -m "first mod" file --config-option servers:global:http-library=serf > echo "second mod" >> file > svn ci -m "second mod" file --config-option servers:global:http-library=neon > > Case 4 *fails* > > Case 5 > svn ci -m "first mod" file --config-option servers:global:http-library=neon > echo "second mod" >> file > svn ci -m "second mod" file --config-option servers:global:http-library=serf > echo "third mod" >> file > svn ci -m "third mod" file --config-option servers:global:http-library=neon > > Case 5 *fails*. > > > Effectively once your working copy is used with serf you can not go back > to neon for this particular *CASE*. > > Regards, > Arwin Arni
Re: [PATCH] NODES.dav_cache in wc.db is always set to NULL in serf.
ra_serf in trunk, speaking HTTPv2 with the server, doesn't make use of the dav_cache. But I can see how that might be a problem when switching between serf and neon, because neon *does* consult the dav cache (which in your case, I'm guessing, must be stale). At a minimum, if ra_serf isn't going to consult the dav cache, it should at least be sure to invalidate whatever is stored therein so as not to trip up neon. On 04/19/2011 11:57 AM, Arwin Arni wrote: > Hi All, > > NODES.dav_cache in wc.db is always set to NULL in serf. > > Is it intentional? > > If not attached patch would fix it. > > Why I am concerned? > > I was testing one scenario(master-slave setup) which failed becuase of > NODES.dav_cache being NULL. > > Scenario: > > I was trying to understand r900797(Commit where subsequent commits(from same > WC) to the same out-dated proxy(out-dated only after the first commit) was > made to succeed via ) > > For some time I could see it fail with trunk binary later reduced with the > following cases, > > Case 1: > svn ci -m "first mod" file --config-option servers:global:http-library=neon > echo "second mod" >> file > svn ci -m "second mod" file --config-option servers:global:http-library=neon > > Case 1 succeeds. > > Case 2: > svn ci -m "first mod" file --config-option servers:global:http-library=serf > echo "second mod" >> file > svn ci -m "second mod" file --config-option servers:global:http-library=serf > > Case 2 succeeds > > Case 3 > svn ci -m "first mod" file --config-option servers:global:http-library=neon > echo "second mod" >> file > svn ci -m "second mod" file --config-option servers:global:http-library=serf > > Case 3 succeeds. > > Case 4 > svn ci -m "first mod" file --config-option servers:global:http-library=serf > echo "second mod" >> file > svn ci -m "second mod" file --config-option servers:global:http-library=neon > > Case 4 *fails* > > Case 5 > svn ci -m "first mod" file --config-option servers:global:http-library=neon > echo "second mod" >> file > svn ci -m "second mod" file --config-option servers:global:http-library=serf > echo "third mod" >> file > svn ci -m "third mod" file --config-option servers:global:http-library=neon > > Case 5 *fails*. > > > Effectively once your working copy is used with serf you can not go back to > neon for this particular *CASE*. > > Regards, > Arwin Arni -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: [PATCH] NODES.dav_cache in wc.db is always set to NULL in serf.
On Tue, Apr 19, 2011 at 10:57 AM, Arwin Arni wrote: > Hi All, > > NODES.dav_cache in wc.db is always set to NULL in serf. > > Is it intentional? Yes. Serf does not require this cache. > If not attached patch would fix it. > > Why I am concerned? > > I was testing one scenario(master-slave setup) which failed becuase of > NODES.dav_cache being NULL. > > Scenario: > > I was trying to understand r900797(Commit where subsequent commits(from same > WC) to the same out-dated proxy(out-dated only after the first commit) was > made to succeed via ) > > For some time I could see it fail with trunk binary later reduced with the > following cases, > > Case 1: > svn ci -m "first mod" file --config-option servers:global:http-library=neon > echo "second mod" >> file > svn ci -m "second mod" file --config-option servers:global:http-library=neon > > Case 1 succeeds. > > Case 2: > svn ci -m "first mod" file --config-option servers:global:http-library=serf > echo "second mod" >> file > svn ci -m "second mod" file --config-option servers:global:http-library=serf > > Case 2 succeeds > > Case 3 > svn ci -m "first mod" file --config-option servers:global:http-library=neon > echo "second mod" >> file > svn ci -m "second mod" file --config-option servers:global:http-library=serf > > Case 3 succeeds. > > Case 4 > svn ci -m "first mod" file --config-option servers:global:http-library=serf > echo "second mod" >> file > svn ci -m "second mod" file --config-option servers:global:http-library=neon > > Case 4 *fails* > > Case 5 > svn ci -m "first mod" file --config-option servers:global:http-library=neon > echo "second mod" >> file > svn ci -m "second mod" file --config-option servers:global:http-library=serf > echo "third mod" >> file > svn ci -m "third mod" file --config-option servers:global:http-library=neon > > Case 5 *fails*. > > > Effectively once your working copy is used with serf you can not go back to > neon for this particular *CASE*. False. This is a *cache*, meaning, if it is NULL you don't lose any information, it may just take longer to get that information. If the cache is NULL, neon will populate it as needed for increased performance. Note that the cache is inherently NULL the first time you use neon when checking out a working copy, and yet it works. :) -Hyrum
Re: [PATCH] Add a test in dav-mirror-autocheck.sh to showcase a out-of-date slave related bug
On 04/19/2011 07:44 AM, Mark Phippard wrote: On Mon, Apr 18, 2011 at 7:41 AM, Daniel Shahaf wrote: On Mon, 18 Apr 2011 07:08 -0400, "Mark Phippard" wrote: I know why it fails, but I would not expect it to fail as a user, even with a proxy. I did not look at Arwin's test but it does not require a WC to show the failure. This also fails: $ svn mkdir url://branches/branch1 $ svn mkdir url://branches/branch2 Because in the second mkdir, the slave's idea of HEAD is behind master's and user's idea of HEAD. As I said, I know why it fails. That does not mean we should not identify these problems and look for ways to solve them. If proxy was a first class feature it would know you were running a command where the all of the HTTP requests should be proxied and this would not fail. I agree it would be nice if this worked, but given that we have to remain sane to people who open an RA session to the slave before it has synced up I'm afraid it might be tricky to address. (That corresponds to the case of concurrent commits --- two people attempting Mark's two mkdirs concurrently.) Separately: we might want to teach the wc that one repos_url (out of several with the same repos_uuid) is preferred in given circumstances... then we could have '^mirror/' and '^master/' syntaxes. To reiterate, there is no WC involved here. So a change like that is not needed. This problem exists with commands that are run on URL's alone. As you know most of our SVN commands involved many HTTP requests and the problem here is that some of them are handled by the proxy and others are proxied to the master. A solution would likely require the proxy to have more awareness of the SVN command being executed so that it knew to proxy all of the requests back to the master rather than handle any of them off the local replica. FWIW at [1] I originally sent a patch which would provide a RA API to set a request header 'SVN-ACTION' indicating high level svn operation. [1] http://svn.haxx.se/dev/archive-2010-01/0101.shtml With regards Kamesh Jayachandran
[PATCH] NODES.dav_cache in wc.db is always set to NULL in serf.
Hi All,
NODES.dav_cache in wc.db is always set to NULL in serf.
Is it intentional?
If not attached patch would fix it.
Why I am concerned?
I was testing one scenario(master-slave setup) which failed becuase of
NODES.dav_cache being NULL.
Scenario:
I was trying to understand r900797(Commit where subsequent commits(from
same WC) to the same out-dated proxy(out-dated only after the first
commit) was made to succeed via )
For some time I could see it fail with trunk binary later reduced with
the following cases,
Case 1:
svn ci -m "first mod" file --config-option servers:global:http-library=neon
echo "second mod" >> file
svn ci -m "second mod" file --config-option servers:global:http-library=neon
Case 1 succeeds.
Case 2:
svn ci -m "first mod" file --config-option servers:global:http-library=serf
echo "second mod" >> file
svn ci -m "second mod" file --config-option servers:global:http-library=serf
Case 2 succeeds
Case 3
svn ci -m "first mod" file --config-option servers:global:http-library=neon
echo "second mod" >> file
svn ci -m "second mod" file --config-option servers:global:http-library=serf
Case 3 succeeds.
Case 4
svn ci -m "first mod" file --config-option servers:global:http-library=serf
echo "second mod" >> file
svn ci -m "second mod" file --config-option servers:global:http-library=neon
Case 4 *fails*
Case 5
svn ci -m "first mod" file --config-option servers:global:http-library=neon
echo "second mod" >> file
svn ci -m "second mod" file --config-option servers:global:http-library=serf
echo "third mod" >> file
svn ci -m "third mod" file --config-option servers:global:http-library=neon
Case 5 *fails*.
Effectively once your working copy is used with serf you can not go back
to neon for this particular *CASE*.
Regards,
Arwin Arni
Index: subversion/libsvn_ra_serf/merge.c
===
--- subversion/libsvn_ra_serf/merge.c (revision 1095083)
+++ subversion/libsvn_ra_serf/merge.c (working copy)
@@ -308,8 +308,7 @@
/* We now need to dive all the way into the WC to update the
* base VCC url.
*/
- if ((! SVN_RA_SERF__HAVE_HTTPV2_SUPPORT(ctx->session))
- && ctx->session->wc_callbacks->push_wc_prop)
+ if (ctx->session->wc_callbacks->push_wc_prop)
{
svn_string_t checked_in_str;
const char *checked_in;
* subversion/libsvn_ra_serf/merge.c
(end_merge) : Remove extra check
Patch by : Arwin Arni
Re: [PATCH] to help benchmark.py run on windows
On Apr 19, 2011, at 15:32 , Neels Hofmeyr wrote: > On Mon, 2011-04-18 at 19:47 -0400, Greg Stein wrote: >> Applied in r1094816. >> >> On Mon, Apr 18, 2011 at 18:44, Greg Stein wrote: >>> On Mon, Apr 18, 2011 at 07:04, Alan Wood wrote: Hi devs, I have just been looking at running the benchmarks and have got to the stage where I can run it on windows. This attached patch fixes three issues with the script: 1) use of file:// when I'm sure that file:/// is correct from previous discussions on this list > > This particular change is not necessary -- code extract with > annotations: > > base = tempfile.mkdtemp() # base == '/tmp/dir123' > repos = j(base, 'repos')# repos == '/tmp/dir123/repos' > file_url = 'file://%s' % repos # file_url == 'file://' + '/tmp/...' > > With your change, file_url becomes file:tmp/..., which is still > valid, but nonsense :) (BTW, the script would not have worked if there > had been only two slashes.) On Windows, the path returned by mkdtemp() is something like C:\users\billga~1\appdata\local\temp\tmpfoobar with no leading slash, so an extra slash makes the URL valid. The directory path could even have spaces in it, if the user wishes. For a geeky script like this, we don't have to be paranoid. Steve > > Thanks for your patch, Alan! > > ~Neels > 2) make sure no \ end up is repos url file:// 3) at error handler to rmtree to handle the windows read-only files. I have removed the "which svn" command, not sure how to do this so it is only removed on windows as I'm not really a python person. I hope this is useful. I haven't provided a log message as I don't really think it can be applied without a bit of editing. >>> >>> Yes, it will certainly be useful. Thanks! >>> >>> I'll fold your changes into the scripts. It is handy because I don't >>> have a Windows machine for testing. Please go ahead and continue >>> sending your patches to the list! >>> >>> (or if you'd like, we can offer you direct commit access to the >>> suite1/ directory) >>> >>> Cheers, >>> -g >>> > > -- Stephen Butler | Senior Consultant elego Software Solutions GmbH Gustav-Meyer-Allee 25 | 13355 Berlin | Germany tel: +49 30 2345 8696 | mobile: +49 163 25 45 015 fax: +49 30 2345 8695 | http://www.elegosoft.com Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Re: [PATCH] to help benchmark.py run on windows
On Mon, 2011-04-18 at 19:47 -0400, Greg Stein wrote: > Applied in r1094816. > > On Mon, Apr 18, 2011 at 18:44, Greg Stein wrote: > > On Mon, Apr 18, 2011 at 07:04, Alan Wood wrote: > >> Hi devs, > >> I have just been looking at running the benchmarks and have got to the > >> stage where I can > >> run it on windows. > >> > >> This attached patch fixes three issues with the script: > >> 1) use of file:// when I'm sure that file:/// is correct from previous > >> discussions on this list This particular change is not necessary -- code extract with annotations: base = tempfile.mkdtemp() # base == '/tmp/dir123' repos = j(base, 'repos')# repos == '/tmp/dir123/repos' file_url = 'file://%s' % repos # file_url == 'file://' + '/tmp/...' With your change, file_url becomes file:tmp/..., which is still valid, but nonsense :) (BTW, the script would not have worked if there had been only two slashes.) Thanks for your patch, Alan! ~Neels > >> 2) make sure no \ end up is repos url file:// > >> 3) at error handler to rmtree to handle the windows read-only files. > >> > >> I have removed the "which svn" command, not sure how to do this so it is > >> only removed on > >> windows as I'm not really a python person. > >> I hope this is useful. > >> I haven't provided a log message as I don't really think it can be > >> applied without a bit of > >> editing. > > > > Yes, it will certainly be useful. Thanks! > > > > I'll fold your changes into the scripts. It is handy because I don't > > have a Windows machine for testing. Please go ahead and continue > > sending your patches to the list! > > > > (or if you'd like, we can offer you direct commit access to the > > suite1/ directory) > > > > Cheers, > > -g > >
JavaHL crash in finalize method if dispose called
In getting 1.7 to work with Subclipse I ran into some problems where it seems that JavaHL does not have the same thread-safety that previous versions had. Bert seemed to indicate that what was working in earlier versions was probably just luck. In current Subclipse versions, I construct one, and only one, SVNClient object and use it from all threads. Fortunately, I have a boolean in place where I can simply say that SVNClient is not threadsafe and this changes the behavior of Subclipse so that instead constructs a new SVNClient object for each usage. When I made this change, all works fine. However, one reason I went to the single object approach a long time ago was that I learned that the SVNClient.dispose() method should be called when you are done with the object so that the native resources can be freed. The way Subclipse was architected this was going to be difficult to do, so I went with the single object approach. Since it seemed that I was going to need to go back to having multiple objects, I figured that I needed to fix this issue of not calling dispose(). So I went through all of Subclipse and made this change as needed so that the resources are cleaned up. But now I am finding that I get crashes. What it looks to me is happening, is that when I call dispose JavaHL is cleaning up its resources properly. However, when the JVM later comes along and calls the finalize() method on the objects as they are GC'd then JavaHL crashes in the finalize code. Probably because it tries to free something that dispose already freed. Here is the stacktrace I get from the crash: Thread 8 Crashed: Java: Finalizer 0 libsvnjavahl-1.0.dylib 0x00012011ae61 SVNBase::findCppAddrForJObject(_jobject*, _jfieldID**, char const*) + 119 (SVNBase.cpp:67) 1 libsvnjavahl-1.0.dylib 0x000120121781 SVNClient::getCppObject(_jobject*) + 35 (SVNClient.cpp:85) 2 libsvnjavahl-1.0.dylib 0x00012013146e Java_org_apache_subversion_javahl_SVNClient_finalize + 97 (org_apache_subversion_javahl_SVNClient.cpp:86) Is this fixable? Should I just skip calling dispose and let the finalize method take care of it? I think you are not supposed to rely on that method being called as the JVM does not make promises to call it. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: svn commit: r1094692 - /subversion/trunk/subversion/libsvn_repos/rev_hunt.c
"C. Michael Pilato" writes: >> + if (changed_path && changed_path->prop_mod) >> +break; >> + if (svn_dirent_is_root(path, strlen(path))) > > I'd need to get my bearings before reviewing the meat of this change, but > this use of the wrong path API caught my eye. These aren't dirents. They > are probably fspaths. Yes, I wrote this patch in 1.6 first. It's fixed on trunk. -- Philip
Re: svn commit: r1094692 - /subversion/trunk/subversion/libsvn_repos/rev_hunt.c
On 04/18/2011 02:38 PM, phi...@apache.org wrote:
> Author: philip
> Date: Mon Apr 18 18:38:58 2011
> New Revision: 1094692
>
> URL: http://svn.apache.org/viewvc?rev=1094692&view=rev
> Log:
> Make "blame -g" more efficient on the server when svn:mergeinfo is
> large.
>
> * subversion/libsvn_repos/rev_hunt.c
> (get_merged_mergeinfo): Use the FS path_changed API to check
>for property changes before doing expensive svn:mergeinfo
>manipulations, don't treat newly created paths as a merge,
>avoid allocating some empty hashes.
>
> Modified:
> subversion/trunk/subversion/libsvn_repos/rev_hunt.c
>
> Modified: subversion/trunk/subversion/libsvn_repos/rev_hunt.c
[...]
> @@ -1045,6 +1046,30 @@ get_merged_mergeinfo(apr_hash_t **merged
>apr_pool_t *subpool = svn_pool_create(pool);
>apr_hash_t *curr_mergeinfo, *prev_mergeinfo, *deleted, *changed;
>svn_error_t *err;
> + svn_fs_root_t *root;
> + apr_hash_t *changed_paths;
> + const char *path = old_path_rev->path;
> +
> + /* Getting/parsing/diffing svn:mergeinfo is expensive, so only do it
> + if there is a property change. */
> + SVN_ERR(svn_fs_revision_root(&root, repos->fs, old_path_rev->revnum,
> + subpool));
> + SVN_ERR(svn_fs_paths_changed2(&changed_paths, root, subpool));
> + while (1)
> +{
> + svn_fs_path_change2_t *changed_path = apr_hash_get(changed_paths,
> + path,
> +
> APR_HASH_KEY_STRING);
> + if (changed_path && changed_path->prop_mod)
> +break;
> + if (svn_dirent_is_root(path, strlen(path)))
I'd need to get my bearings before reviewing the meat of this change, but
this use of the wrong path API caught my eye. These aren't dirents. They
are probably fspaths.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Distributed Development On Demand
