rhuij...@apache.org wrote on Thu, Mar 28, 2013 at 12:00:55 -:
> Author: rhuijben
> Date: Thu Mar 28 12:00:54 2013
> New Revision: 1462060
>
> URL: http://svn.apache.org/r1462060
> Log:
> * roadmap.html
> Mark the profiling step of new apis as completed. Over the last few months
> I profile
I have a function that looks like this:
static svn_error_t *f(svn_fs_t *fs)
{
svn_fs_t *ft = svn_fs_open(fs);
svn_fs_verify_root(ft, r42);
}
I'd like the 'verify' call to bypass any information that is already
cached: I don't mind if it the 'verify' process caches informa
Fix for this is included in the 1.6.21 and 1.7.9 tarballs up for testing.
I've checked that they aren't vulnerable to the this issue. I'd
welcome others doing the same.
Source packages here:
https://dist.apache.org/repos/dist/dev/subversion/
On Tue, Mar 12, 2013 at 11:40 AM, Ben Reser wrote:
>
The 1.7.9 release artifacts are now available for testing/signing.
Please get the tarballs from
https://dist.apache.org/repos/dist/dev/subversion
and add your signatures there. I plan to try and release on April
4th so please try and get your votes/signatures in place by April
3rd EOD.
Thanks!
Log:
[[[ Followup to r1420334: Adding new tests.
* subversiom/bindings/swig/python/tests/checksum.py
Writing new tests to ensure robustness of svn_checksum_match(),
svn_checksum_dup() and svn_checksum_empty_checksum().
Patch by: Shivani Poddar ]]]
Regards,
Shivani Poddar,
irc-nick - Pods
Index
The 1.6.21 release artifacts are now available for testing/signing.
Please get the tarballs from
https://dist.apache.org/repos/dist/dev/subversion
and add your signatures there. I plan to try and release on April
4th so please try and get your votes/signatures in place by April
3rd EOD. Thanks!
Mattias Engdegård wrote:
>T he conflict message "local %s %s, incoming %s %s upon %s" in
> svn_cl__get_human_readable_tree_conflict_description is not correctly
> prepared
> for localisation.
[...]
Thanks, Mattias. Your patch certainly looks to me like a good improvement.
> The patch assumes
Bert Huijben wrote on Thu, Mar 28, 2013 at 23:42:18 +:
> --parents is supported for urls below a repository, but I agree that we
> should reduce the number of errors that show this hint.
>
In that case the error code should be SVN_ERR_FS_NOT_FOUND, not ENOENT.
--parents is supported for urls below a repository, but I agree that we should
reduce the number of errors that show this hint.
Bert
Sent from Windows Mail
From: Daniel Shahaf
Sent: Friday, March 29, 2013 12:25 AM
To: dev@subversion.apache.org
Another one I randomly ran in
Another one I randomly ran into:
% $svn mkdir -qmm file://$PWD/r/$RANDOM
svn: E02: Try 'svn mkdir --parents' instead?
svn: E02: Can't create directory
'/home/daniel/src/svn/t1/r/db/transactions/1-5.txn': No such file or directory
I get what's happening --- the code, presumably, checks
The conflict message "local %s %s, incoming %s %s upon %s" in
svn_cl__get_human_readable_tree_conflict_description is not correctly
prepared for localisation.
First, two of the parameters are inserted untranslated (in English),
making proper translation impossible; second, piecing together a
Bert Huijben wrote on Thu, Mar 28, 2013 at 22:33:09 +0100:
> I don't say that we should stop reading fsfs.conf, but why should we
> introduce a 'fs.conf' at the repos level for things that don't belong
> at that level and most likely 99% of our users will never use?
>
fs.conf will be going away.
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: donderdag 28 maart 2013 22:06
> To: dev@subversion.apache.org
> Subject: Re: Opening the repository hooks environment file
>
> On 28.03.2013 21:50, Bert Huijben wrote:
> >
> >> -Original Message-
> >> F
On 28.03.2013 22:07, Julian Foad wrote:
> Branko Čibej wrote:
>
>> On 28.03.2013 21:38, Julian Foad wrote:
>>> I like the focused API, but I also see how the automatic merge can be
>>> considered to fill in a bit of missing functionality that merge_peg ought
>>> to
>>> provide.
>>>
>>> Perhaps
Branko Čibej wrote:
> On 28.03.2013 21:38, Julian Foad wrote:
>> I like the focused API, but I also see how the automatic merge can be
>> considered to fill in a bit of missing functionality that merge_peg ought to
>> provide.
>>
>> Perhaps we can have both. Teach merge_peg to DTRT in this c
On 28.03.2013 21:50, Bert Huijben wrote:
>
>> -Original Message-
>> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
>> Philip Martin
>> Sent: donderdag 28 maart 2013 19:32
>> To: Bert Huijben
>> Cc: dev@subversion.apache.org
>> Subject: Opening the repository hooks enviro
On 15 March, Bert Huijben wrote:
> Julian Foad wrote:
>> === Pre-conflict and post-conflict operating modes.
>>
>> The problem is basically that we have confused two different operating
>> modes -- with different purposes and requirements -- for such a callback:
>>
>> (1) Sometimes we call
> -Original Message-
> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
> Philip Martin
> Sent: donderdag 28 maart 2013 19:32
> To: Bert Huijben
> Cc: dev@subversion.apache.org
> Subject: Opening the repository hooks environment file
>
> "Bert Huijben" writes:
>
> > T
On 28.03.2013 21:38, Julian Foad wrote:
> Now with a patch for discussion.
>
> (More below...)
>
> Julian Foad wrote:
>>> Brane told me that while updating the JavaHL API he noticed that the new
>>> svn_client_merge_automatic() is Yet Another Merge API, and would prefer make
>>> the existing JavaHL
Now with a patch for discussion.
(More below...)
Julian Foad wrote:
>> Brane told me that while updating the JavaHL API he noticed that the new
>> svn_client_merge_automatic() is Yet Another Merge API, and would prefer make
>> the existing JavaHL merge API encompass that functionality rather than
On Thu, Mar 28, 2013 at 1:11 PM, Daniel Shahaf wrote:
> This is normally done on trunk then merged to the branch...
Whoops, forgot what branch I was on. Fixed in r1462293 and r1462294.
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.
bre...@apache.org wrote on Thu, Mar 28, 2013 at 20:05:21 -:
> Author: breser
> Date: Thu Mar 28 20:05:21 2013
> New Revision: 1462286
>
> URL: http://svn.apache.org/r1462286
> Log:
> * CHANGES: First draft of 1.7.9 changes.
>
> Modified:
> subversion/branches/1.7.x/CHANGES
This is normal
On Thu, Mar 28, 2013 at 1:02 PM, Ivan Zhakov wrote:
> Sorry, it seems I missed something important: what is the hooks
> environment file? But I agree that we need explicit mod_dav_svn option
> to enable this functionality if this new in svn 1.8.
http://svn.apache.org/r1380608
On Thu, Mar 28, 2013 at 10:31 PM, Philip Martin
wrote:
> "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 work
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.
The are several TODO notes
"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
On 28.03.2013 18:08, Daniel Shahaf wrote:
> Ben Reser wrote on Thu, Mar 28, 2013 at 09:30:05 -0700:
>> On Thu, Mar 21, 2013 at 10:41 AM, Branko Čibej wrote:
>>> However it would avoid a possible security issue or two as well. IMO our
>>> documentation is correct and we should fix the code to behav
Bo Chen wrote on Thu, Mar 28, 2013 at 13:00:15 -0400:
> I am now working on understanding the flow when a user is doing a commit,
> what exactly happens in the SVN client, and what exactly happens in the SVN
> server, in the code level.
I suggest that you run a commit on ra_local (file:///) and s
Ben Reser wrote on Thu, Mar 28, 2013 at 09:30:05 -0700:
> On Thu, Mar 21, 2013 at 10:41 AM, Branko Čibej wrote:
> > However it would avoid a possible security issue or two as well. IMO our
> > documentation is correct and we should fix the code to behave as documented.
>
> I don't think we ever c
Thanks for the suggestion.
I need to modify the SVN source code for a project, so I need to look
through and understand the source code.
I am now working on understanding the flow when a user is doing a commit,
what exactly happens in the SVN client, and what exactly happens in the SVN
server, i
On Thu, Mar 21, 2013 at 10:41 AM, Branko Čibej wrote:
> However it would avoid a possible security issue or two as well. IMO our
> documentation is correct and we should fix the code to behave as documented.
I don't think we ever came to a conclusion on this. However, Bert had
some important com
On Thu, Mar 28, 2013 at 7:37 AM, Daniel Shahaf wrote:
> I also prefer the backend-specific approach since the other one can be
> implemented with hook scripts just the same.
>
> The "penalty" would have been optional and off-by-default, though.
Personally I really like the svnlook idea. Though I
On Thu, Mar 28, 2013 at 7:53 AM, Bo Chen wrote:
> I am struggling to locate the source code by which the SVN client can
> transfer the delta to the server upon a commit operation. Can anyone give me
> some hints for it, e.g., which source file file is responsible to
> transferring the delta (after
Markus Schaber wrote:
> Hi, Bo,
>
> Von: Bo Chen [mailto:bo.irvine.c...@gmail.com]
>> I am just starting to investigate into the source code of SVN.
>>
>> Can you please give me more introductions for it. In my previous
>> experiences for network communication, I can simply establish a netwo
Hi, Bo,
Von: Bo Chen [mailto:bo.irvine.c...@gmail.com]
> On Thu, Mar 28, 2013 at 10:56 AM, Daniel Shahaf wrote:
> > Bo Chen wrote on Thu, Mar 28, 2013 at 10:53:24 -0400:
> > > I am struggling to locate the source code by which the SVN client can
> > > transfer the delta to the server upon a commi
On Thu, Mar 28, 2013 at 11:11:15AM -0400, Bo Chen wrote:
> I am just starting to investigate into the source code of SVN.
>
> Can you please give me more introductions for it. In my previous
> experiences for network communication, I can simply establish a network
> connection, and send the inform
The RA layer encapsulates the choice of URL scheme (file://, svn://, and
http://) so the client and server logics don't need to worry about it.
svnserve opens its own sockets, but with libsvn_ra_serf the syscalls
happen in a dependency library (serf).
Bo Chen wrote on Thu, Mar 28, 2013 at 11:11:1
I am just starting to investigate into the source code of SVN.
Can you please give me more introductions for it. In my previous
experiences for network communication, I can simply establish a network
connection, and send the information to the server via the socket, and that
is it. Why SVN is so c
Bo Chen wrote on Thu, Mar 28, 2013 at 10:53:24 -0400:
> I am struggling to locate the source code by which the SVN client can
> transfer the delta to the server upon a commit operation. Can anyone give
> me some hints for it, e.g., which source file file is responsible to
> transferring the delta (
I am struggling to locate the source code by which the SVN client can
transfer the delta to the server upon a commit operation. Can anyone give
me some hints for it, e.g., which source file file is responsible to
transferring the delta (after the delta has been computed) to the server ?
Thanks for
C. Michael Pilato wrote on Thu, Mar 28, 2013 at 10:12:38 -0400:
> On 03/28/2013 08:22 AM, Daniel Shahaf wrote:
> > See above, and yes if we end up opting for the backend-specific
> > implementation then the new fs.conf file will go away.
>
> If this is to be done at all, it should be backend-speci
On Thu, Mar 28, 2013 at 03:02:29PM +0200, 'Daniel Shahaf' wrote:
> Bert Huijben wrote on Thu, Mar 28, 2013 at 13:39:36 +0100:
> > In many companies everything must be scanned and in most companies that use
> > virusscanners on Windows the average user is not even allowed to configure
> > skipping s
On 03/28/2013 09:52 AM, Daniel Shahaf wrote:
> svn log
> https://svn.apache.org/repos/infra/websites/production/www/content@PREV
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb7bdb1df in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb7bde825 in __GI_abort () at abort.c:91
On 03/28/2013 08:22 AM, Daniel Shahaf wrote:
> See above, and yes if we end up opting for the backend-specific
> implementation then the new fs.conf file will go away.
If this is to be done at all, it should be backend-specific. No sense in
preemptively penalizing every backends' (current and fut
% $svn log
https://svn.apache.org/repos/infra/websites/production/www/content@PREV
subversion/libsvn_subr/dirent_uri.c:1571: (apr_err=235000)
svn: E235000: In file 'subversion/libsvn_subr/dirent_uri.c' line 1571:
assertion failed (! svn_path_is_url(relative))
Bert Huijben wrote on Thu, Mar 28, 2013 at 13:39:36 +0100:
>
>
> > -Original Message-
> > From: Daniel Shahaf [mailto:danie...@elego.de]
> > Sent: donderdag 28 maart 2013 13:22
> > To: Bert Huijben
> > Cc: dev@subversion.apache.org
> > Subject: Re: svn commit: r1462054 - in /subversion/br
On Thu, Mar 28, 2013 at 12:18 PM, Philip Martin
wrote:
> 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
> -Original Message-
> From: Daniel Shahaf [mailto:danie...@elego.de]
> Sent: donderdag 28 maart 2013 13:22
> To: Bert Huijben
> Cc: dev@subversion.apache.org
> Subject: Re: svn commit: r1462054 - in /subversion/branches/verify-at-
> commit/subversion: include/svn_fs.h libsvn_fs/fs-loader
Bert Huijben wrote on Thu, Mar 28, 2013 at 12:52:51 +0100:
>
>
> > -Original Message-
> > From: danie...@apache.org [mailto:danie...@apache.org]
> > Sent: donderdag 28 maart 2013 12:37
> > To: comm...@subversion.apache.org
> > Subject: svn commit: r1462054 - in /subversion/branches/verify
> -Original Message-
> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
> Philip Martin
> Sent: donderdag 28 maart 2013 12:18
> To: Johan Corveleyn
> Cc: phi...@apache.org; dev@subversion.apache.org
> Subject: Re: svn commit: r1461590 - in /subversion/trunk/subversion:
>
Philip Martin wrote on Thu, Mar 28, 2013 at 12:09:30 +:
> 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.
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
Stefan Sperling wrote on Thu, Mar 28, 2013 at 12:49:46 +0100:
> On Thu, Mar 28, 2013 at 11:36:50AM -, danie...@apache.org wrote:
> > Author: danielsh
> > Date: Thu Mar 28 11:36:50 2013
> > New Revision: 1462054
> >
> > URL: http://svn.apache.org/r1462054
> > Log:
> > On the verify-at-commit br
> -Original Message-
> From: danie...@apache.org [mailto:danie...@apache.org]
> Sent: donderdag 28 maart 2013 12:37
> To: comm...@subversion.apache.org
> Subject: svn commit: r1462054 - in /subversion/branches/verify-at-
> commit/subversion: include/svn_fs.h libsvn_fs/fs-loader.c libsvn_f
On Thu, Mar 28, 2013 at 11:36:50AM -, danie...@apache.org wrote:
> Author: danielsh
> Date: Thu Mar 28 11:36:50 2013
> New Revision: 1462054
>
> URL: http://svn.apache.org/r1462054
> Log:
> On the verify-at-commit branch, add a backend-independent implementation:
> a db/fs.conf file.
As I sai
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
stef...@apache.org wrote on Wed, Mar 27, 2013 at 21:53:02 -:
> Author: stefan2
> Date: Wed Mar 27 21:52:57 2013
> New Revision: 1461865
>
> URL: http://svn.apache.org/r1461865
> Log:
> On the fsfs-format7: Introduce a framework for space and time-
> efficient storage of binary data. For deta
On Wed, Mar 27, 2013 at 3:10 PM, wrote:
> Author: philip
> Date: Wed Mar 27 14:10:54 2013
> New Revision: 1461590
>
> URL: http://svn.apache.org/r1461590
> Log:
> Fix issue 4339, diff suffix scanning invalid read at last chunk boundary.
>
> * subversion/libsvn_diff/diff_file.c
> (find_identical
59 matches
Mail list logo
