Greg Stein writes:
> On Tue, Aug 10, 2010 at 14:41, Paul Burba wrote:
>> On Tue, Aug 10, 2010 at 12:18 AM, Greg Stein wrote:
>>...
>>> For example,
>>>
>>> $ svn cp A/B C
>>> $ svn revert C/D/file
>>>
>>> That should error.
>>>
>>> $ svn revert C
>>>
>>> Should succeed, and undo the copy that w
Daniel Shahaf writes:
> I figure this patch can't do any harm (except cost another file-read when a
> write-lock or txn-current-lock is being acquired), and it might as well
> help, so I committed it in r984990.
>> @@ -594,7 +598,11 @@ static svn_error_t *
>>err = get_lock_on_filesystem(lock
stef...@apache.org writes:
> Author: stefan2
> Date: Sun Aug 8 19:41:11 2010
> New Revision: 983474
>
> URL: http://svn.apache.org/viewvc?rev=983474&view=rev
> Log:
> Memcached is often slower than a single file access.
Doesn't that depend on the type of filesystem used and the resources
allocat
Greg Stein writes:
> But that said, there is an argument for combining all three conceptual
> tables into one. Is that was you guys were suggesting?
Yes. The tables are so similar. For example, base_node's
repos_id/repos_relpath/revnum and the working_node's
copyfrom_id/copyfrom_relpath/copyfr
"Bert Huijben" writes:
> How would this handle deleted nodes in one layer (then some overlays) and
> then calling _read_children(). I think that would become a union/select over
> multiple layers? We already had some performance issues there in the past
> and I hope this only makes this query eas
Doug Reeder writes:
> svn, version 1.6.4 (r38063)
That's old.
>compiled Aug 7 2009, 11:08:17
> running under OS X 10.5.8 on a Intel Core 2 Duo (i.e. a 64-bit
> processor)
>
> resolve --accept theirs-conflict fails on a CONFLICTED-PATH with a
> directory component, but works fine when CONFL
I was wondering why the regression tests were substantially slower on
my laptop running Ubuntu/Lucid compared to my desktop running
Debian/stable. The laptop is newer and I was expecting it to be about
10% slower than the desktop, yet the laptop takes 17mins compared to
10mins for the desktop. It
"Bert Huijben" writes:
>> * subversion/tests/cmdline/upgrade_tests.py
>> (text_base_path): Restore MD5 support removed in r960036.
>
> I think the real fix would be to upgrade to SHA1 (and add the
> mapping in the pristines table) in the upgrade step. I expected that
> this was already handled?
Johan Corveleyn writes:
> Ok, thanks. In the meantime I saw that there is not that much
> difference anymore between GNU diff and svn_diff, after running the
> latter from a release build, and disabling my anti-virus (which makes
> me wonder why my anti-virus slows down svn_diff (impact when open
"Bert Huijben" writes:
> In the old entries format we only kept one checksum, while we can have two
> pristine files, so just keeping it as MD5 can't solve all the issues.
That's NODE_DATA, nothing to do with single-db.
> But we can't just assume that we never see a collision with MD5 over an
>
shrinivasan writes:
> I am compiling subversion with kwallet support.
> But, Getting the following error.
>
>
> ./configure --with-kwallet --prefix=/home/shrinivasan/svn-builds/1.6.13
> cd subversion/libsvn_auth_kwallet && /usr/share/apr-1.0/build/libtool
> --tag=CXX --silent --mode=link g++ -g
anatoly techtonik writes:
> Not really. In Rietveld project we call "svn diff" by upload.py script
> used to send diffs for review to remote server. We can't instruct
> users to copy config dir, so we need to do this automatically. That
> means copying the whole config dir and comment only one op
Philip Martin writes:
> anatoly techtonik writes:
>
>> Not really. In Rietveld project we call "svn diff" by upload.py script
>> used to send diffs for review to remote server. We can't instruct
>> users to copy config dir, so we need to do this automat
"Bert Huijben" writes:
>> -Original Message-
>> From: Julian Foad [mailto:julian.f...@wandisco.com]
>>
>> If, instead, we construct each the PRISTINE table entry at the point
>> where we're converting an entry from the entries file, then we can
>> calculate both checksums on the fly, and
"Bert Huijben" writes:
>> -Original Message-
>> From: phi...@apache.org [mailto:phi...@apache.org]
>> Sent: dinsdag 24 augustus 2010 16:13
>> To: comm...@subversion.apache.org
>> Subject: svn commit: r988550 - in /subversion/trunk/subversion:
>> libsvn_wc/entries.c tests/cmdline/upgrade_t
"Bert Huijben" writes:
>> From: Philip Martin [mailto:philip.mar...@wandisco.com]
>> Sent: dinsdag 24 augustus 2010 16:58
>> To: Bert Huijben
>> Cc: 'Julian Foad'; 'Bert Huijben'; dev@subversion.apache.org
>> Subject: Re: svn commit
phi...@apache.org writes:
> Author: philip
> Date: Wed Aug 25 09:55:35 2010
> New Revision: 988956
>
> URL: http://svn.apache.org/viewvc?rev=988956&view=rev
> Log:
> Fix some uses of unitialised variables identified by valgrind.
>
> * subversion/libsvn_wc/update_editor.c
> (add_directory, add_fi
phi...@apache.org writes:
> Author: philip
> Date: Wed Aug 25 13:53:27 2010
> New Revision: 989108
>
> URL: http://svn.apache.org/viewvc?rev=989108&view=rev
> Log:
> Stop writing to pool memory after the pool has been cleared, something
> that started to happen when svn_ra_open4 introduced a sessi
Greg Stein writes:
> I'm pleased to announce the 0.7.0 release of serf.
Subversion's redirect tests fail with serf 0.7.0, the client redirects
to
/svn-test-work/repositories/redirect_tests-2
instead of
http://localhost:/svn-test-work/repositories/redirect_tests-2
--
Philip
One of the problems with single-db upgrade is that write_entry, called
from svn_wc__write_upgraded_entries, want's to be able to query the
new database using things like svn_wc__db_scan_addition. This fails
because svn_wc__db_pdh_parse_local_abspath encounters old .svn dirs
and creates pdhs with t
"Bert Huijben" writes:
>> -Original Message-
>> From: Philip Martin [mailto:philip.mar...@wandisco.com]
>> Sent: donderdag 26 augustus 2010 16:34
>> To: dev@subversion.apache.org
>> Subject: Two svn_wc__db_t for single-db upgrade
>>
>>
Greg Stein writes:
> I'm with Bert. The entry writing is used *only* for upgrades. It may
> as well be tuned for exactly that: track any information you need
> while performing the upgrade.
I realise we can do that, but I don't see why it's better. It means
creating/using our own database in me
Philip Martin writes:
> [I'm aware that we don't add incomplete children when we add a
> complete parent, but the children don't care about siblings. And it
> should be easy to fix.]
Turns out we do this the right way. We add a parent, and incomplete
directory childr
"Bert Huijben" writes:
> The hard cases, like missing and obstructions of metadata are not handled
> and cannot be handled by the single-db WC-DB api as these cannot occur there
> . (There are no tests for this, and anything that looks like a test for this
> is disabled for some 4th tree reason).
"Bert Huijben" writes:
> But even in that case there can be different information in the parent stub
> and the child directory itself.
That's why I want to use the database.
>
>> > So you are suggesting that we change the DB API's to provide this
>> > information (or keep providing this multi-d
"Bert Huijben" writes:
> In case of a delete of copy you can have
>
> BASE normal (checked out N levels up)
> NODE_DATA normal (descendant of copy 2 levels up)
> NODE_DATA normal (child of copy 1 level up)
> WORKING: deleted (node itself)
>
> _read_info() will give you the information from workin
"Bert Huijben" writes:
> I really think that it is much easier to just walk the entries files using
> an old style-lock, constructing a new sqlite db 'upgrade.db' somewhere
> outside the normal location using upgrade specific code.
That might be another way to do it. If we construct a temporary
Greg Stein writes:
> Back up a step. *What* data do you need to query? Maybe there is a more
> direct solution.
Upgrade calls _scan_addition on the parent when writing a node, see
entries.c:write_entry.
> I very much dislike a special mode for wc_db. It just screams "hack".
If I put the new da
"Bert Huijben" writes:
> (I see a completely different test failure on the Windows bot)
On Linux I get the same as Hyrum.
> Can you run this same test with single-db?
In single-db on Linux I get 3 Failures rather than 1 Error:
.F..F..F
.
Time: 139.1
"Bert Huijben" writes:
> This is one of the revert tests if I remember correctly?
Yes.
> I think we have to move these checks in the revert code instead of forcing
> old lock behavior. But I really don't know what we should do here, except
> for maybe revving svn_client_revertX(), to move the o
"Bert Huijben" writes:
> All tests Pass or XPass on Windows with single-db, except for the
> upgrade tests. (Philip is working on this one)
Should work now.
--
Philip
Julian Foad writes:
> CAUTION: It's just a hacky script and it has some very rough edges. In
> particular, it will assimilate any versioned directory, *including
> things like externals that it shouldn't touch*. If you have any
> externals, you must delete them (the populated directories, not t
dmitry boyarintsev writes:
> Hello Subversion-dev,
>
> I can see, that there's no much of interest in Pascal bindings.
> Well, that's quite understandable because of Pascal language not
> being popular.
>
> Anyway, I'll publish the headers on my site.
>
> Thank you for your great product!
You ar
pbu...@apache.org writes:
> Author: pburba
> Date: Thu Sep 2 18:10:01 2010
> New Revision: 992042
> @@ -5718,6 +5849,37 @@ get_mergeinfo_paths(apr_array_header_t *
> merge_cmd_baton->ctx->cancel_baton,
> scratch_pool));
"Hyrum K. Wright" writes:
> Sure, but is this "bring us back to parity with 1.6" work, or is it
> "new stuff we can do with wc-ng" work? If the former, it's certainly
> a release blocker. If the latter, I'm not so sure
We currently have a regression from 1.6, wc-ng cannot record the
revert
Justin Erenkrantz writes:
> When compiled with SVN_DEBUG and SQLITE3_DEBUG and 'svn st' against a
> svn trunk WC, a number of things pop out.
>
> We perform 28,062 SQL queries.
It's not just repeat queries that are the problem, we simply make too
many queries. This is mainly because the code is
Branko Čibej writes:
> On 06.09.2010 12:16, Philip Martin wrote:
>> To use a per-directory query strategy we would probably have to cache
>> data in memory, although not to the same extent as in 1.6. We should
>> probably avoid having Subversion make status callbacks in
If I lock a file, modify it and commit over DAV then the lock is
visible in the pre-commit hook, and if the commit fails the lock
remains valid.
If I delete the file, rather than modify it, then the lock gets
removed before the pre-commit hook runs, and if the commit fails the
lock is gone. This
vijayaguru writes:
> +#--
> +# Test for issue #3471 'svn up touches file w/ lock & svn:keywords property'
> +#
> +# Marked as XFail until that issue is fixed.
> +def update_with_file_lock_and_keywords_property_set(sbox):
> + """
Erik Huelsmann writes:
> There are however, a few queries in 'entries.c' which operate directly on
> BASE_/WORKING_NODE. These queries will need to be migrated. However, in our
> old entries, we don't have the concept of op_depths and op roots. That makes
> it a bit hard to migrate the entries fi
Daniel Trebbien writes:
> [[[
> Add a command line option to the svnsync init, sync, and copy-revprops
> subcommands (--source-encoding) that allows the user to specify the
> character encoding of translatable properties from the source
> repository. This is needed to allow svnsync to import some
Senthil Kumaran S writes:
> In the previous versions of subversion ie., 1.5.x or 1.4.x the keyword
> will not expand, but this is not the case with 1.6.x in which it gets
> expanded for the first update. This is what the issue #3471 is about
> and the committed patch tests that.
I'm still confus
vijayaguru writes:
> In 1.5.x & 1.6.x, the keyword is expanded for the first update and
> timestamp is changed for further updates. Here We are just locking the
> file with keywords property set and we are not committing the file.Then
> running "svn update" should expand the keyword & change the
Philip Martin writes:
> vijayaguru writes:
>
>> In 1.5.x & 1.6.x, the keyword is expanded for the first update and
>> timestamp is changed for further updates. Here We are just locking the
>> file with keywords property set and we are not committing the file.Then
&g
cmpil...@apache.org writes:
> Author: cmpilato
> Date: Tue Aug 31 16:47:22 2010
> New Revision: 991239
>
> URL: http://svn.apache.org/viewvc?rev=991239&view=rev
> Log:
> Add code to parse skel-type request bodies in mod_dav_svn (honoring
> the LimitRequestBody Apache configuration directive), and
Julian Foad writes:
> On Tue, 2010-09-14, Daniel Shahaf wrote:
>> Johan Corveleyn wrote on Sat, Sep 11, 2010 at 00:02:16 +0200:
>> > On Fri, Sep 10, 2010 at 11:45 PM, wrote:
>> > > http://subversion.tigris.org/issues/show_bug.cgi?id=3474
>> > >
>> > > --- Additional comments from joha...@ti
"Bert Huijben" writes:
>> -Original Message-
>> From: Philip Martin [mailto:philip.mar...@wandisco.com]
>>
>> Perhaps we should simply notify for all nodes? Perhaps each
>> individual client should be deciding which notifications to suppress?
&g
Stefan Sperling writes:
> The translation issues is why I didn't use the APR_[U]INT64_T_FMT.
> It's either using it and make life hard for translators, or have these
> warnings... neither solution is perfect. Or is there a better solution?
Have two format strings and pick the right one based on
"Bert Huijben" writes:
>> +-- STMT_UPDATE_COPYFROM_TO_INHERIT_1
>> +UPDATE NODES SET
>> + repos_id = null,
>> + repos_path = null,
>> + revision = null
>> +WHERE wc_id = ?1 AND local_relpath = ?2
>> + AND op_depth IN (SELECT op_depth FROM nodes
>> + WHERE wc_id = ?1 AND loca
Erik Huelsmann writes:
> We're now back to a single failure. It's in the relocation-verification code
> in db-test.c (line 1505). With the half-hour I've spent so far, I wasn't
> able to locate it, but I have to move to other business now. Hopefully
> you'll be able to find it.
It's the differen
Erik Huelsmann writes:
> However, the UPDATE_RECURSIVE_BASE_REPO query doesn't take any of that into
> account and simply rewrites all repo_ids to be the new repo to relocate to.
> That doesn't seem correct though: if other nodes had different repository
> sources, those should probably be exclud
Daniel Shahaf writes:
>> return svn_error_return(
>> svn_error_createf(SVN_ERR_INCORRECT_PARAMS, NULL,
>> - _("Number '%s' is out of range '[%lu,
>> %lu]'"),
>> + _("Number '%s' is out of range '[%llu,
>> %llu]'"),
Daniel Shahaf writes:
> Philip Martin wrote on Wed, Sep 22, 2010 at 11:47:19 +0100:
>> Daniel Shahaf writes:
>> > minval is an apr_uint64_t, so shouldn't the format string use
>> > APR_UINT64_FMT?
>>
>> See this thread
>>
>> http:
Julian Foad writes:
> It might be worth adding a pool parameter so that any of the
> print-into-a-substing variants can be used.
Perhaps we can avoid these complications in the code. Could we invoke
the C pre-processor during the po-update stuff? Perhaps on the output
of gettext?
--
Philip
Greg Stein writes:
> On Wed, Sep 22, 2010 at 05:39, wrote:
>>...
>> +++ subversion/trunk/subversion/libsvn_wc/wc-queries.sql Wed Sep 22 09:39:45
>> 2010
>> @@ -215,7 +215,7 @@ update nodes set properties = ?3
>> where wc_id = ?1 and local_relpath = ?2
>> and op_depth in
>> (select op_dep
Erik Huelsmann writes:
>> > @@ -312,7 +312,7 @@ WHERE wc_id = ?1 AND local_relpath = ?2;
>> > update nodes set translated_size = ?3, last_mod_time = ?4
>> > where wc_id = ?1 and local_relpath = ?2
>> > and op_depth = (select op_depth from nodes
>> > - where wc_id = ?1 and loc
Greg Stein writes:
> On Thu, Sep 23, 2010 at 11:22, wrote:
>>...
>> +++ subversion/trunk/subversion/libsvn_wc/wc_db.c Thu Sep 23 15:22:52 2010
>>...
>> @@ -3665,7 +3665,7 @@ svn_wc__db_op_copy(svn_wc__db_t *db,
>> SVN_ERR(svn_sqlite__bindf(stmt, "issisnnnt",
>> src_pdh
Greg Stein writes:
> On Thu, Sep 23, 2010 at 05:16, wrote:
>> Author: philip
>> Date: Thu Sep 23 09:16:28 2010
>> New Revision: 1000370
>>
>> URL: http://svn.apache.org/viewvc?rev=1000370&view=rev
>> Log:
>> Use lower case in SQL queries instead of mixing upper and lower
>> cases inconsistently
These two queries don't work:
-- STMT_SELECT_WORKING_NODE_CHILDREN_1
SELECT local_relpath FROM nodes
WHERE wc_id = ?1 AND parent_relpath = ?2
AND op_depth = (SELECT MAX(op_depth) FROM nodes
WHERE wc_id = ?1 AND parent_relpath = ?2 AND op_depth > 0);
-- STMT_COUNT_WORKING
Philip Martin writes:
> but I don't know how to fix the second one. How do I count the number
> of rows returned by that GROUP BY query?
>From IRC the following was suggested
-- STMT_SELECT_WORKING_NODE_CHILDREN_1
SELECT DISTINCT local_relpath FROM nodes
WHERE wc_id = ?1 AND
Philip Martin writes:
>> This leads on to the problem of selecting just the highest op_depth
>> for each child. Is it possible to get one query to return just the
>> highest op_depth for each child?
>
> I suspect we will still want to do this at some point.
This was s
julianf...@apache.org writes:
> Author: julianfoad
> Date: Fri Sep 24 11:27:36 2010
> New Revision: 1000816
> +/* ### Huh? This looks like it's expected to overwrite the temp file
> + *DST_ABSPATH, but it would return an error if the destination
> + exists. And
Greg Stein writes:
> Step back and look at that code.
>
> The gather_children() got a bit more complicated because I was trying
> to get the list of children from BASE_NODE and WORKING_NODE, and union
> those together (or skip the union altogether in certain cases). With
> NODES, it becomes one s
Julian Foad writes:
> Greg Stein wrote:
>> Why are tests failing because of the different values?
>
> I think it's not because the op_depth value is different, but because
> creating a row with a different op_depth now in some cases means
> creating an *additional* row, and the rest of the code i
Greg Stein writes:
> Seems like this will make things even more complicated. I'd be in
> favor of *not* switching to NODES unless/until the op_depth is done
> properly. If you switch early, then you're going to require another
> format bump to reset all the op_depth fields to their proper values.
Julian Foad writes:
>> I believe the answer is "often". A simple 'svn status' will need to
>> distinguish between 'A' and 'R', and that is done by checking
>> prior_deleted.
>>
>> And no... this amount of denormalization will not hurt us.
>
> OK. I know that "svn status" speed is a big deal.
I
Stefan Fuhrmann writes:
> On 27.09.2010 21:44, Ramkumar Ramachandra wrote:
>> Could you tell me which tools you use to profile the various
>> applications in trunk? I'm looking to profile svnrdump to fix some
>> perf issues, but OProfile doesn't seem to work for me.
>
> Under Linux, I'm using Va
Daniel Näslund writes:
> On Tue, Sep 28, 2010 at 03:45:33PM +0200, Daniel Shahaf wrote:
>> Daniel Näslund wrote on Mon, Sep 27, 2010 at 22:09:26 +0200:
>>
>> err_abort() is called when an error object hadn't been svn_error_clear()'d.
>> (The error creation installed err_abort() as a pool cleanup
Greg Stein writes:
> To do this, it seems that we're going to need to expose (from wc_db.h)
> a structure containing "all" the row data. Thankfully, this big ol'
> structure is *private* to libsvn_wc, and we can change it at will
> (unlike svn_wc_status_t). I would suggest that we use a callback
scott mc writes:
Please write a log message:
http://subversion.apache.org/docs/community-guide/conventions.html#log-messages
Please use spaces rather than tabs for indentation.
> Index: subversion/libsvn_subr/config_file.c
> ===
>
"Hyrum K. Wright" writes:
> 1.6.13 tarballs are up for testing and signing.
Summary:
+1 to release.
Platform:
Linux (Debian/stable).
Verified:
signatures, MD5 checksums, SHA1 checksums
only expected difference compared to tags/1.6.13
Tested:
1.6.13 tarball with local dependenc
scott mc writes:
> On Wed, Sep 29, 2010 at 5:45 PM, Philip Martin
> wrote:
>
>> Please write a log message:
> -
>
> This patch makes use of find_directory() on Haiku to locate the proper
> directories to use. Currently B_USER_SETTINGS_DIRECTORY points to
&
s...@apache.org writes:
> Author: stsp
> Date: Sun Oct 3 16:05:19 2010
> New Revision: 1003986
> * subversion/mod_authz_svn/mod_authz_svn.c
> (get_access_conf, req_check_access, req_check_access): Use (const *)NULL
>as sentinel for apr_pstrcat(), instead of NULL.
That should be "(char *)"
Julian Foad writes:
> I'm glad you are keen to keep only relevant warnings visible, but the
> sight of so many unnecessary casts in our code makes me squirm. :-(
>
> The NULL macro is intended for use as a pointer. When a combination of
> compiler, system library headers and APR headers conspire
Stefan Sperling writes:
> I think the warning is printed only for functions that are marked in
> a special way that GCC looks for.
> The svn_* functions don't have such markers.
They don't have __attribute((sentinel)) but there is the same need for
a cast, no more or less, than the function call
Philip Martin writes:
> Stefan Sperling writes:
>
>> I think the warning is printed only for functions that are marked in
>> a special way that GCC looks for.
>> The svn_* functions don't have such markers.
>
> They don't have __attribute((sentinel)) but
Greg Stein writes:
> On Tue, Oct 5, 2010 at 16:54, Julian Foad wrote:
>>...
>> Earlier today on IRC, Philip and I came to the conclusion that a copy of
>> a mixed-rev subtree (at least from BASE) should be all at the *same*
>> op_depth.
>
> Right. This is why the original NODES table had copyfro
I'd like to enable NODES as a replacement for BASE_NODE and
WORKING_NODE. This would involve bumping the format number, and old
working copies would get automatically upgraded.
This is not the final NODES data model. It currently just uses
NODES.op_depth as 0 or 2 to indicate the equivalent of B
"Hyrum K. Wright" writes:
> wrote:
>>
>> The disadvantages include: a wc upgrade, the testsuite is slightly
>> (maybe 2% on my machine) slower.
>
> Are there any explanations for this behavior?
I haven't profiled it. It could be the NODES queries that do
"op_depth = (SELECT MAX(op_depth)" as t
style...@apache.org writes:
> Author: stylesen
> Date: Wed Oct 6 14:41:35 2010
> New Revision: 1005065
> +static svn_boolean_t
> +password_get_gpg_agent(const char **password,
> + apr_hash_t *creds,
> + const char *realmstring,
> +
Greg Stein writes:
> What about upgrades from f10 or f19?
Upgrading from 1.6 works just as well with NODES as with BASE/WORKING,
we write NODES with op_depth 0 or 2. Ugrading from wcng 19 to 20 is
very simple, we just copy into NODES with op_depth 0 or 2.
--
Philip
Daniel Shahaf writes:
>> Greg Stein writes:
>>
>> > What about upgrades from f10 or f19?
>>
>> Upgrading from 1.6 works just as well with NODES as with BASE/WORKING,
>> we write NODES with op_depth 0 or 2. Ugrading from wcng 19 to 20 is
>> very simple, we just copy into NODES with op_depth 0
Daniel Shahaf writes:
> Okay, but I can do the f16->f18 upgrade using head of trunk, right?
Yes, as far as I know. None of that code has changed.
--
Philip
Bob Fletcher writes:
> To show the problem:
> (1) Create a project with an external file.
> (2) Modify and Commit a change to an actual working copy of the file
> (in another project).
> (3) Update the original project with the external file - even when
> omitting externals.
> This gives
Philip Martin writes:
> I'd like to enable NODES as a replacement for BASE_NODE and
> WORKING_NODE. This would involve bumping the format number, and old
> working copies would get automatically upgraded.
This has been committed to trunk.
--
Philip
Julian Foad writes:
> This tells me that the hand-optimization is actually harmful and the
> compiler does a 10% better job by itself.
>
> Have I made a mistake?
>
> What are the results for your system?
>
> (I'm using GCC 4.4.1 on an Intel Centrino laptop CPU.)
On my system (Intel Core 2 Duo, G
phi...@apache.org writes:
> Author: philip
> Date: Fri Oct 8 09:53:19 2010
> New Revision: 1005751
> + PM: Yes, we have overwrite sematics. The FS layer on the server has
> + magic that converts the copy of the r12 descendant into a replace if
> + the descendant exists in r10. The client
Branko Čibej writes:
> Got into this a bit late, sorry, but I'm not at all happy about this
> change.
>
> If we ignore the issue with long-running SVN processes ... ok, let's
> assume that changing umask requires that you restart daemons ...
>
> I cannot ignore two issues:
>
> * The default
Bob Fletcher writes:
> OK. I was able to create the error using the command line. The
> following are the steps I took. I sure hope this is helpful. (In the
> steps below, I changed the name of my company in the URL to xxx.)
Thanks for doing this. I tried your recipe on my Linux machine and it
Ramkumar Ramachandra writes:
> Right, got it. Can I get a +1 for the following patch?
If we are going to use the APR atomic interface then the two reads
should use apr_atomic_read32.
It would be better to use svn_atomic__init_once. It's a clear
indication that we are doing once only initialisa
Bob Fletcher writes:
> For example, in response to svn --version, I would get
> svn, version 1.7.0 (dev build)
>compiled Oct 9 2010, 00:09:42
>
> As you suggested, I downloaded the binaries just posted today on the same
> site.
> Now in response to svn --version, I get
> svn, version 1.7.0
Erik Huelsmann writes:
> This is why I'm now proposing that we stop to leave behind the
> -unchanged- files which are part of a copy or move operation.
That sounds reasonable to me. I'd be surprised if making a versioned
copy and then using revert to make it unversioned is something that
users
Gavin Beau Baumanis writes:
>> --- subversion-1.7.xx-svn/subversion/libsvn_subr/config_impl.h
>> (revision
>> 1002735)
>> +++ subversion-1.7.xx-svn/subversion/libsvn_subr/config_impl.h
>> (working copy)
>> @@ -114,8 +114,11 @@
>>or svn_config_get_user_config_path() instead. */
>
Ramkumar Ramachandra writes:
> Hi Philip,
>
> [sorry about the delayed reply: I had a bad internet connection]
>
> Philip Martin writes:
>> If we are going to use the APR atomic interface then the two reads
>> should use apr_atomic_read32.
>>
>> It would
Stefan Küng writes:
> svnadmin create repo
> svn co file:///d:/repo wc
> cd wc
> mkdir test
> mkdir test\test
> mkdir test\test\test
> svn add test
> svn ci . -m "adding folders"
> svn rm test\test\test
> svn ci . -m "removing folder"
> svn rm test\test
> svn ci . -m "removing folder"
Only two l
Philip Martin writes:
> The first commit leaves A/B,not-present,op_depth=0 and that's correct.
> The second delete converts that to op_depth=2. That's wrong (I
> think). The A/B,not-present,op_depth=0 node should continue to exist,
> but perhaps we need an op_depth=2 nod
"Bert Huijben" writes:
>> - if (err && SVN_WC__ERR_IS_NOT_CURRENT_WC(err))
>> + SVN_ERR(svn_wc__db_pdh_parse_local_abspath(&pdh, &local_relpath, db,
>> + local_abspath,
>> svn_sqlite__mode_readonly,
>> + scratch_pool, scratch_pool));
>>
In 1.7 we insist that "switch --relocate" only acts on a whole working
copy. In 1.6 we allow parts of the working copy to be relocated.
What should 1.7 do when upgrading a partially switched working copy?
At present it ignores partial relocation and upgrades the whole
working copy based on the re
Stefan Küng writes:
> I'm still using r1023755 from trunk, but I haven't seen a commit which
> I think would fix this:
>
> There's a massive memory leak somewhere. I can't check out even small
> projects anymore since the memory consumption raises very fast and
> reaches the limit of my available
"C. Michael Pilato" writes:
> On 10/19/2010 12:41 PM, Stefan Küng wrote:
>> I tried to check out npp:
>> https://notepad-plus.svn.sourceforge.net/svnroot/notepad-plus/trunk
>>
>> Nothing special about file sizes or number of files.
>
> Can you try it without SSL? (Is that possible?) I seem to
1 - 100 of 2844 matches
Mail list logo
