Philip Martin writes:
> We could do this:
>
> Index: subversion/svnserve/svnserve.c
> ===
> --- subversion/svnserve/svnserve.c(revision 1480565)
> +++ subversion/svnserve/svnserve.c(working copy)
> @@
Ivan Zhakov writes:
> On Wed, May 8, 2013 at 1:00 PM, Bert Huijben wrote:
>>
>> The fix resolves the symptoms, but I would guess it might be better
>> to make the thread create (and destroy) its own pool, while using
>> some proper iterpool in the function that creates the pools. Handing
>> a te
Ben Reser writes:
> There are some changes in STATUS that we should finish voting for. Of
> particular note is Branko's case-sensitivity change.
It doesn't seem to be attracting votes so postpone the change to 1.9 and
roll a tarball without it.
--
Certified & Supported Apache Subversion Downl
Philip Martin writes:
> br...@apache.org writes:
>
>> Author: brane
>> Date: Thu Apr 25 13:48:46 2013
>> New Revision: 1475772
>>
>> URL: http://svn.apache.org/r1475772
>> Log:
>> Fix issue #4361 (user/group names in authz files are case-insen
Mark Phippard writes:
> I think Synchronized is a better solution, but will not object if you
> want to make the change.
I'm a novice as far as Java is concerned, I don't know which style is
preferred.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/dow
Mark Phippard writes:
> On Mon, Apr 29, 2013 at 7:47 AM, Philip Martin
> wrote:
>> markp...@apache.org writes:
>>
>>> Author: markphip
>>> Date: Fri Apr 26 19:48:34 2013
>>> New Revision: 1476359
>>>
>>> URL: http://svn.apache.org
br...@apache.org writes:
> Author: brane
> Date: Thu Apr 25 13:48:46 2013
> New Revision: 1475772
>
> URL: http://svn.apache.org/r1475772
> Log:
> Fix issue #4361 (user/group names in authz files are case-insensitive).
>
> * subversion/include/svn_config.h
> (svn_config_create2): New, revised fr
markp...@apache.org writes:
> Author: markphip
> Date: Fri Apr 26 19:48:34 2013
> New Revision: 1476359
>
> URL: http://svn.apache.org/r1476359
> Log:
> JavaHL: fix a thread safety bug that has been observed in Subclipse.
>
> The Java SimpleDateFormat class is not thread safe. Solved by
> synchron
Robert Wruck writes:
> I just came across this issue. Assume we have two branches:
> branches/A where a particular subdir exists
> branches/B where this subdir was replaced by an svn:externals entry
> Is this a known issue?
http://subversion.tigris.org/issues/show_bug.cgi?id=4360
That mentions
Daniel Shahaf writes:
> Philip Martin wrote on Fri, Apr 26, 2013 at 15:07:01 +0100:
>> defines a single group (= mp) and single access rule (= rw). Now that
>> is still a contrived example but something like this is more likely:
>>
>> [groups]
Mark Phippard writes:
> That said, I did misunderstand the proposal. I thought it was
> suggesting we should just make things case-INsensitive. I thought
> that would be the wrong decision at this point.
>
> The file has always been case sensitive. So if you are just fixing a
> bug that was fo
Bert Huijben writes:
> /subversion/trunk/subversion/libsvn_wc/wc-metadata.sql
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: quoted-printable
>
> We should probably also test this on an upgrade from entries as in that
> case we don't get through the
"Bert Huijben" writes:
>> However the fact that the missing empty cache is created and populated
>> is just a fortuitous side effect of how we handle externals[1].
>
> There is nothing special about externals in the following code.
I've added a regression test for inherited properties to
upgrade
Paul Burba writes:
>> # We expect the repos root property to show up here!
>>
>> 1.9.0-dev@1475809>svn pg svn:auto-props . --show-inherited-props
>>
>> 1.9.0-dev@1475809>
Is that expected? The inherited property is not in the 1.7 working
copy. Do you expect upgrade to contact the repository an
Julian Foad writes:
> I am only questioning the assignment of a 1.8.0 "release blocker"
> milestone.
That was simply because Branko suggested he was targeting 1.8.0. We
have to decide now because I don't think we would put this into a minor
release (the last case-sensitivity change went into 1.
Philip Martin writes:
> Julian Foad writes:
>
>> So what exactly is broken, behaviour-wise? Is authorization done with
>> case-insensitive username checking in the server, and the "svnauthz"
>> tool is broken in that it fails to do case-insensitive matching o
Julian Foad writes:
> So what exactly is broken, behaviour-wise? Is authorization done with
> case-insensitive username checking in the server, and the "svnauthz"
> tool is broken in that it fails to do case-insensitive matching of
> usernames? Or something else?
The tool and the server do the
Branko Čibej writes:
> I also propose, in advance, that we include this change in 1.8. It
> should be relatively non-invasive as far as code is concerned, but of
> course we'll have to yell loudly in the release notes about the changed
> behaviour.
I've raised http://subversion.tigris.org/issues
Gabriela Gibson writes:
> Index: subversion/libsvn_subr/config.c
> ===
> --- subversion/libsvn_subr/config.c (revision 1465268)
> +++ subversion/libsvn_subr/config.c (working copy)
> @@ -464,7 +464,7 @@ make_string_from_option(co
Consider an authz file:
[/]
pm = rw
PM = r
When we parse the key=value lines we handle the key case-insensitively
so only one value, the last, gets stored as the second value overrides
the first. However we also store the exact case of the first key and
that is what is checked when quer
"Bert Huijben" writes:
> Well, explicitly not initializing variables is another way of adding
> undefined behavior.
You are suggesting that all heap variables be explicitly initialised to
zero before being initialised to the correct values. We don't do that
for stack variables, why is it so imp
Blair Zajac writes:
> It looks like the wrong revision number was given in STATUS, as it's a
> tomcat commit:
>
> http://svn.apache.org/viewvc?view=revision&revision=r1471029
r1471028 is the revision that should have been proposed/voted/merged.
--
Certified & Supported Apache Subversion Downlo
"C. Michael Pilato" writes:
> Strictly speaking, though, any of the 'read',
> 'mark', 'skip' or 'write' operations will trigger the
> open-if-not-yet-opened() logic of the lazyopen stream.
As will 'skip' and 'seek', i.e. all public operations apart from
'close'. The new flag allows 'close' to t
Stefan Fuhrmann writes:
> On Tue, Apr 23, 2013 at 6:54 PM, Philip Martin
> wrote:
>> At the start of the log
>> you say it is essential to use consistent configs. Does using NULL
>> result in consistent configs?
>>
>
> Consistent as in "same as in all
Ivan Zhakov writes:
> On Tue, Apr 23, 2013 at 5:04 PM, wrote:
>> Author: philip
>> Date: Tue Apr 23 13:04:42 2013
>> New Revision: 1470936
>>
>> URL: http://svn.apache.org/r1470936
>> Log:
>> Significantly reduce the number of open files during a typical update
>> over ra_serf by using lazy-ope
stef...@apache.org writes:
> Author: stefan2
> Date: Mon Apr 22 22:26:39 2013
> New Revision: 1470738
>
> URL: http://svn.apache.org/r1470738
> Log:
> Make svn_fs_verify accept a FS_CONFIG parameter similar to svn_fs_open()
> and svn_fs_create(). Use that in svn_repos_verify_fs2 to check FS with
Julian Foad writes:
> I don't think Daniel's assertion made things clearer. Here's my code
> rearrangement suggestion, moving the 'directory' variable into a
> smaller scope and avoiding it ever being uninitialized:
Second guessing the optimizer is hard:
../src/subversion/libsvn_fs_fs/tree.c:9
Daniel Shahaf writes:
> What would a better fix be?
It's hard to say which is probably why these warnings have not been
addressed so far. The warning is a 'maybe':
../src/subversion/libsvn_fs_fs/tree.c:929:27: warning: 'directory' may be used
uninitialized in this function [-Wmaybe-uninitiali
bl...@apache.org writes:
> Author: blair
> Date: Thu Apr 18 18:41:55 2013
> New Revision: 1469520
>
> URL: http://svn.apache.org/r1469520
> Log:
> open_path(): silence compiler warning.
>
> subversion/libsvn_fs_fs/tree.c: In function 'open_path':
> subversion/libsvn_fs_fs/tree.c:916: warning: 'dir
Branko Čibej writes:
> On 18.04.2013 11:49, br...@apache.org wrote:
>> Author: brane
>> Date: Thu Apr 18 09:49:03 2013
>> New Revision: 1469248
>>
>> URL: http://svn.apache.org/r1469248
>> Log:
>> Fixed issue #4338 (Install mod_dontdothat with install-tools)
>
> It would be a great idea if someon
Bert Huijben writes:
> And both merge and patch allow adding directories with files inside...
You can certainly add any such files to the changelist but using the
changelist to commit is a problem since the commit doesn't include the
directory.
Changelist support for directories would be one so
Philip Martin writes:
> "C. Michael Pilato" writes:
>
>> 'svn merge' comes to mind as one that, like patch, does not always have
>> explicitly named targets.
>
> Yes, merge is another candidate for this behaviour.
I think it's a reasonable su
"C. Michael Pilato" writes:
> On 04/17/2013 09:43 AM, Philip Martin wrote:
>> The behaviour looks simple to define for 'patch' and 'merge', I was
>> thinking about 'svn add --force' which marks all the unversioned files
>> for additio
"C. Michael Pilato" writes:
> On 04/17/2013 06:43 AM, Philip Martin wrote:
>> [dev CC'd]
>>
>> Nick writes:
>>
>>> The 'patch' subcommand does not seem to support applying a changelist
>>> description to the files that ar
"C. Michael Pilato" writes:
> On 04/17/2013 07:34 AM, Bert Huijben wrote:
>>> With 1.6 and 1.8 I get:
>>>
>>> $ svn up wc/some-file-that-does-not-exist
>>> At revision 3
>>>
>>> With 1.7 I get:
>>>
>>> $ svn up wc/some-file-that-does-not-exist
>>> Updating 'wc/some-file-that-does-not-exis
"Bert Huijben" writes:
>> -Original Message-
>> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
>> Philip Martin
>> Sent: woensdag 17 april 2013 12:54
>> To: dev@subversion.apache.org
>> Subject: Update targets that do
We allow the user to update a target that is not present in the working
copy: it lets the user bring in a target that is present in a different
revision. We also allow the update of an existing target to a revision
in which the target does not exist: the target gets marked as
'not-present'. Both
[dev CC'd]
Nick writes:
> The 'patch' subcommand does not seem to support applying a changelist
> description to the files that are part of the patch. Any plans to
> support this?
>
> (Should I be asking this on the dev list?)
That sounds like a useful feauture. The list of files affected by
Roderich Schupp writes:
> On Tue, Apr 16, 2013 at 11:35 AM, Philip Martin
> wrote:
>> Can you provide a bit more explanation for the removal of
>> revprop_table and changelists from MAY_BE_NULL
>
> Can't pretend that I understand Swig very well either...
> But
Philip Martin writes:
> Yes, we send 13.
>
> HTTP/1.1 500 Internal Server Error\r
> Date: Tue, 16 Apr 2013 13:17:44 GMT\r
> Server: Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.1e DAV/2
> SVN/1.9.0-dev\r
> Content-Length: 291\r
> Connection: close\r
> Content-Typ
"C. Michael Pilato" writes:
> On 04/16/2013 07:40 AM, Philip Martin wrote:
>> Perhaps mod_dav_svn should only return a low level error is a very few
>> carefully controlled circumstances and shoul usually return the more
>> generic "could not begin a trans
Daniel Shahaf writes:
> Philip Martin wrote on Tue, Apr 16, 2013 at 12:40:06 +0100:
>> $ svn -mm mkdir http://localhost:/obj/repo/A
>> svn: E13: Can't move
>> '/home/pm/sw/subversion/obj/repo/db/txn-protorevs/2-b.rev' to
>> '/home/pm/
phi...@apache.org writes:
> Author: philip
> Date: Tue Apr 16 10:12:51 2013
> New Revision: 1468347
>
> URL: http://svn.apache.org/r1468347
> Log:
> Make mod_dav_svn's handling of POST errors more like mod_dav's
> handling of errors for other requests. This makes MKACTIVITY
> and POST return the
Roderich Schupp writes:
> * subversion/bindings/swig/svn_client.i
> Drop three typemaps. The first two are obviously bogus and
> the third is redundant (it's also in svn_containers.swg).
> Index: subversion/bindings/swig/svn_client.i
>
Ben Reser writes:
> On Mon, Apr 15, 2013 at 6:38 AM, Philip Martin
> wrote:
>> Mattias Engdegård writes:
>>
>>> Here is a patch. (I didn't add a newline to the string directly since
>>> it occurs in many places.)
>>
>> The explaination s
Mattias Engdegård writes:
> Here is a patch. (I didn't add a newline to the string directly since
> it occurs in many places.)
The explaination should go in the code not the email otherwise somebody
else may change the code. I don't understand the explaination, is this
to make translation easie
Mattias Engdegård writes:
> Avoid a "condition always true" warning on platforms where char
> is unsigned by default, such as PowerPC and ARM.
>
> * subversion/libsvn_subr/utf_validate.c
> (first_non_fsm_start_char, first_non_fsm_start_char_cstring):
>Add explicit cast to avoid warning when
Philip Martin writes:
> "C. Michael Pilato" writes:
>
>> We know the branch isn't RC-ready, so if we cut a tarball, it would be
>> "beta1".
>
> What needs to happen to make it RC-ready?
CHANGES needs to be completed. Anything else?
--
Philip
"C. Michael Pilato" writes:
> We know the branch isn't RC-ready, so if we cut a tarball, it would be
> "beta1".
What needs to happen to make it RC-ready?
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
One absolute URL is enough, the other can be relative.
Ben Reser writes:
> I tend to think the absolute URL syntax is better for our
> documentation since the only way the relative URL works is if you run
> it while your CWD is in a working copy in that repo.
>
> On Fri, Apr 12, 2013 at 6:32 AM,
Julian Foad writes:
> I suppose I was thinking I couldn't be sure that the same path was
> used in each possible case. Looking at it again, if dst_path is not a
> URL then it would be reasonable to assume that all relevant changes
> are on the same filesystem as dst_path. Even more so if we use
julianf...@apache.org writes:
> Author: julianfoad
> Date: Tue Apr 2 19:53:43 2013
> New Revision: 1463721
>
> URL: http://svn.apache.org/r1463721
> Log:
> Fix some sleep-for-timestamps code: avoid missing some cases where we need
> to sleep -- especially error cases -- and avoid sleeping in some
"C. Michael Pilato" writes:
> Did you perhaps make a small mistake above? If py_hash == NULL, I don't
> think we care need to DECREF if. But perhaps you meant to point out that
> we'd be bypassing the DECREF of py_scratch_pool, instead?
Yes.
--
Certified & Supported Apache Subversion Downloa
cmpil...@apache.org writes:
> Author: cmpilato
> Date: Wed Apr 10 14:38:17 2013
> New Revision: 1466497
> +svn_swig_py_config_auth_walk_func(svn_boolean_t *delete_cred,
> + void *walk_baton,
> + const char *cred_kind,
> +
Mattias Engdegård writes:
> The conflict prompt is no longer localised, probably because of an
> oversight.
Were they localised in the past?
> Index: subversion/svn/conflict-callbacks.c
> ===
> --- subversion/svn/conflict-callbacks
Julian Foad writes:
> * Near past: The recorded commit time, compared with the client-side
> clock time, is within the timestamp granularity and in the past.
>
> - We do need to sleep.
> - My earlier commit eliminated the sleep, which broke this case.
> - This commit fixes this
"Bert Huijben" writes:
> And we use some of this time to see if you have a modern filesystem that
> stores more timestamp details than just seconds (by looking at the existing
> filesystem node passed to the function) and if you have such a filesystem we
> don't sleep at all.
We still sleep on
julianf...@apache.org writes:
> Author: julianfoad
> Date: Thu Apr 4 21:14:06 2013
> New Revision: 1464769
>
> URL: http://svn.apache.org/r1464769
> Log:
> Sleep for timestamps even if using commit times as timestamps.
>
> Before r1463721, 'revert' did not sleep if using commit times, while
> 'ch
"Bert Huijben" writes:
>> -Original Message-
>> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
>> Philip Martin
>> Sent: donderdag 4 april 2013 14:23
>> To: Bert Huijben
>> Cc: 'Philip Martin'; dev@subversion.apa
"Bert Huijben" writes:
>> -Original Message-
>> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
>> Philip Martin
>> Sent: donderdag 4 april 2013 13:19
>> To: dev@subversion.apache.org
>> Subject: issue 4345: switch/delete/
Lieven Govaerts writes:
> On Thu, Apr 4, 2013 at 12:55 AM, phi...@apache.org wrote:
>> Author: philip
>> Date: Wed Apr 3 22:55:37 2013
>> New Revision: 1464228
>>
>> URL: http://svn.apache.org/r1464228
>> Log:
>> Remove (void) casts of ignored return values from ra_serf.
>>
>> * subversion/libs
Prompted by a question on users:
http://subversion.tigris.org/issues/show_bug.cgi?id=4345
- switch a file
- delete the switched file
- run status/info
- commit
The behaviour varies with client version:
1.6) status: D and S, info: switched URL, commit: switched URL.
1.7) status: D, info: s
Ultimately, this calls
> svn_fs_base__rep_contents_checksums() which just does a
> svn_checksum_dup on the checksum in the representation of the kind we
> asked for. So ultimately, that kind test in the if statement ends up
> testing that our functions are following their contract.
>
> On W
As part of http://subversion.tigris.org/issues/show_bug.cgi?id=4344 I
was playing with a BDB repository created by driving the svn_fs API
directly in repos-test.c:node_locations2. This creates a revision where
a file has no checksum. A subsequent commit that modifies the file can
SEGV:
Program r
Branko Čibej writes:
> On 03.04.2013 13:21, phi...@apache.org wrote:
>> Author: philip
>> Date: Wed Apr 3 11:21:29 2013
>> New Revision: 1463922
>>
>> URL: http://svn.apache.org/r1463922
>> Log:
>> * subversion/libsvn_repos/hooks.c (parse_hooks_env): Remove unused variable.
>>
>> Modified:
>>
Branko Čibej writes:
> I thihk there has to be a way to say all of the following:
>
> 1. do not use a hooks-env file at all
> 2. use the default hooks-env file
> 3. use a specific, non-default hooks-env file
Do we need option 2, the default path?
The hooks-env path is specified in apache con
Stefan Sperling writes:
> On Wed, Apr 03, 2013 at 02:58:56PM +0400, Ivan Zhakov wrote:
>> I think result_pool parameter should be replaced with pool member in
>> svn_repos_t structure.
>
> Or, as Philip suggested, we could replace the svn_repos_hooks_setenv()
> function with a new 'hooks_env_path
Ivan Zhakov writes:
> On Wed, Apr 3, 2013 at 4:38 AM, Ben Reser wrote:
>> I've gone ahead and moved the default hooks-env to hooks-env.tmpl.
>> We'll still try to open the file but we won't bother to read it in or
>> parse a completely commented out file unless the user puts a file in
>> place.
julianf...@apache.org writes:
> Author: julianfoad
> Date: Tue Apr 2 19:53:43 2013
> New Revision: 1463721
> after releasing it in other places. We should pick one and be consistent.
> --- subversion/trunk/subversion/libsvn_client/commit.c (original)
> +++ subversion/trunk/subversion/libsvn_cli
Summary:
+1 to release
Platform:
Linux (Debian/wheezy)
Tested:
(local, svn, svn+sasl, serf, neon) x (fsfs, fsfs/pack/shard, bdb)
(serf/v1, neon/v1) x (fsfs, bdb)
swig-pl, swig-py, swig-rb
javahl x (fsfs, bdb)
Results:
All tests PASS
Local dependencies:
apache2-threaded-dev
Summary:
+1 to release
Platform:
Linux (Debian/wheezy)
Tested:
(local, svn, svn+sasl, serf, neon) x (fsfs, fsfs/pack/shard, bdb)
swig-pl, swig-py, swig-rb
javahl x (fsfs, bdb)
Results:
Testsuite fails for diff_tests.py 32 and log_tests.py 30. These are
known problems and not a
Julian Foad writes:
> The attached patch attempts to improve our 'sleep for timestamps'
> coverage, especially in error conditions where the WC has already been
> changed and so we should sleep as well as returning an error. I just
> happened to notice that we currently miss several such cases.
"Bert Huijben" writes:
> The reading of one file for each access to the repository is a more
> than measurable slowdown when profiling operations. (Reading fsfs.conf
> over and over again is one of the most expensive things apache worker
> processes do when I profiled them. I think stefan2 optimi
Stefan Sperling writes:
> If we decide that verifying transactions before commit is a good
> thing, I'd much rather see a new 'svnlook verify' command that can
> be run from the pre-commit hook, instead of this implementation.
A separate process could be a performance hit since it would not shar
Johan Corveleyn writes:
> I can spend more time on this in a week or two, but if you want to dig
> into it sooner, I think a better fix would be something like this
> (untested / uncompiled):
I extended the test and committed your patch in r1462041.
--
Certified & Supported Apache Subversion D
Joe Swatosh writes:
> Okay, thanks for giving me hints on this. As a matter of fact, my apr
> does NOT have a section like this. It is just doing a straight up copy
> of apr.hw. I've downloaded a few different versions of apr and none of
> them have a block like that in apr.hw. Heading over to th
Daniel Shahaf writes:
> Marshall Schor wrote on Tue, Mar 26, 2013 at 15:29:43 -0400:
>> I recently created some new binary files. I happened to pick a name for
>> these
>> that ended in ".data", thinking that would remind me and others in the future
>> that this was just data.
>>
>
> Thanks, r
Joe Swatosh writes:
> Thanks Philip and Bert, perhaps this along with Philip's changes?
>
> [[[
> Index: subversion/include/svn_types.h
> ===
> --- subversion/include/svn_types.h (revision 1460925)
> +++ subversion/include/svn_t
Philip Martin writes:
> $ valgrind -q .libs/lt-diff-diff3-test 15
> ==6097== Invalid read of size 1
> ==6097==at 0x503FD83: find_identical_suffix (diff_file.c:586)
> ==6097==by 0x5040C45: datasources_open (diff_file.c:815)
> ==6097==by 0x503D6B2: svn_diff_diff3
Philip Martin writes:
> $ valgrind -q .libs/lt-mergeinfo-test 6
> ==6075== Invalid read of size 8
> ==6075==at 0x4C2B5A0: memmove (mc_replace_strmem.c:981)
> ==6075==by 0x507A989: svn_rangelist__combine_adjacent_ranges
> (mergeinfo.c:653)
Fixed this with r1460763.
--
Philip
I've been experimenting with GCC's address sanitizer which is a tool for
catching memory problems. It has identified some uses of uninitialised
memory. valgrind also detects problems at the same places:
$ valgrind -q .libs/lt-mergeinfo-test 6
==6075== Invalid read of size 8
==6075==at 0x4C2B
In r1460628 I changed the code to use svn_cstring_strtoui64 and so avoid
ULONG_MAX.
Bert Huijben writes:
> Isn't there an apr variant of this macro we can/should use?
>
> Bert From: Joe Swatosh
> Sent: 25-3-2013 01:01
> To: SVN Dev
> Subject: [PATCH] #include limts.h for ULONG_MAX
> While I foun
Philip Martin writes:
> So it seems that there is a bug in apr_proc_create on Windows.
> Subversion might be able to work around this bug by explicitly passing
> an non-null, empty environment to apr_proc_create.
If Subversion were to start doing this it would probably break lots
Pavel Lyalyakin writes:
> [[
> Before Subversion calls a hook script, it removes all variables --
> including $PATH on Unix, and %PATH% on Windows -- from the
> environment. Therefore, your script can only run another program if
> you spell out that program's absolute name.
> ]]
>
> Is this state
Julian Foad writes:
> Philip Martin wrote:
>
>> I see similar warning for svn_dbg__preamble, svn_dbg__printf,
>> svn_dbg__print_props, svn_error__locate, svn_error__trace when building
>> without -DSVN_DEBUG.
>>
>> The dbg stuff is declared in private/svn_deb
Branko Čibej writes:
>> The declaration of svn_hash__clear is only present for old APR while the
>> definition is always visible. I get this warning:
>>
>> ../src2/subversion/libsvn_subr/hash.c:512:1: warning: no previous prototype
>> for 'svn_hash__clear' [-Wmissing-prototypes]
>>
>> We could
julianf...@apache.org writes:
> Author: julianfoad
> Date: Wed Mar 20 21:14:59 2013
> New Revision: 1459058
> --- subversion/trunk/subversion/include/private/svn_dep_compat.h (original)
> +++ subversion/trunk/subversion/include/private/svn_dep_compat.h Wed Mar 20
> 21:14:59 2013
> @@ -62,6 +62,1
Stefan Sperling writes:
> I agree. I like the idea of allowing users to specify a template in the
> configuration file to control the way a diff tool is invoked.
> I also like the format you proposed. Do you think it would be reasonable
> to add this new template support to the existing diff-cmd
Branko Čibej writes:
> On 18.03.2013 16:12, phi...@tigris.org wrote:
>> http://subversion.tigris.org/issues/show_bug.cgi?id=3913
>>
>> --- Additional comments from phi...@tigris.org Mon Mar 18 08:12:42 -0700
>> 2013 ---
>> The current behaviour is a deliberate design, see the log for r14
Philip Martin writes:
> 'd41d8cd98f00b204e9800998ecf8427e' is the MD5 of the empty string and
> Subversion has special handling of that checksum.
I made a mistake here. 'd41d8cd98f00b204e9800998ecf8427e' is the
checksum of the empty stri
Philip Martin writes:
> Shivani Poddar writes:
>
>> Unless I don't assign the kind and digest some value for the object I
>> declare here , calling svn_checksum_clear() on it will give me a
>> segmentation fault , could you please elaborate more as to
Shivani Poddar writes:
> Unless I don't assign the kind and digest some value for the object I
> declare here , calling svn_checksum_clear() on it will give me a
> segmentation fault , could you please elaborate more as to why should I
> have to call svn_checksum_clear() before assigning the dige
Vincent Lefevre writes:
> On Debian and Ubuntu GNU/Linux machines, when I run "svn log" in some
> working copy or on some repository URL using the svn+ssh scheme, such
> as with
>
> svn log | tail
>
> or, if this is too fast,
>
> svn log | less
>
> (and searching for a pattern near the end of
Paul Burba writes:
> Where we can improve is in skipping the '[Recording | Eliding]
> mergeinfo' notifications if nothing was actually merged.
Essentially we are skipping a reverse merge because we cannot record
it. That's fine by me so long as we make it clear to the user. This is
clear:
$ sv
Shivani Poddar writes:
> On Tue, Mar 19, 2013 at 5:58 PM, Philip Martin
> wrote:
>
>> Shivani Poddar writes:
>>
>> > Index: subversion/bindings/swig/python/tests/checksum.py
>> > ===
>>
Shivani Poddar writes:
> Index: subversion/bindings/swig/python/tests/checksum.py
> ===
> --- subversion/bindings/swig/python/tests/checksum.py (revision 1448005)
> +++ subversion/bindings/swig/python/tests/checksum.py (working copy)
Scott Hartman writes:
> In file
>
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.11\ext\subversion\subversion\libsvn_wc\entries.c'
> line 1666: assertion failed (parent_node || entry->schedule ==
> svn_wc_schedule_normal)
Were there any "Upgraded ..." lines printed before this error? Do you
Gabriela Gibson writes:
> Index: subversion/libsvn_subr/io.c
> ===
> --- subversion/libsvn_subr/io.c (revision 1458203)
> +++ subversion/libsvn_subr/io.c (working copy)
> @@ -2831,7 +2831,105 @@ svn_io_run_cmd(const char
Paul Burba writes:
> On Mon, Mar 18, 2013 at 3:26 PM, Philip Martin
> wrote:
>> This is one of the issues blocking 1.8. I don't really understand the
>> merge behaviour. Consider this test case: a file in a directory,
>> branch, modify the file on the branch:
>
This is one of the issues blocking 1.8. I don't really understand the
merge behaviour. Consider this test case: a file in a directory,
branch, modify the file on the branch:
svnadmin create repo
svn -mm import repo/format file://`pwd`/repo/A/B/f
svn -mm cp file://`pwd`/repo/A ^/A2
svnmucc -mm put
901 - 1000 of 2844 matches
Mail list logo
