On Mon, Dec 20, 2010 at 10:34:46PM -0800, Blair Zajac wrote:
> What about ~/.subversion/cli or ~/.subversion/command-line-client.
> If somebody wants to copy an existing configuration from another
> user, they just can't copy ~/.subversion now.
There are other clients such as TortoiseSVN which hav
On 12/20/10 8:30 PM, C. Michael Pilato wrote:
On 12/20/2010 05:28 PM, Hyrum K. Wright wrote:
In issue #3765, I suggest the possibility of a CVS-style config file
wherein a user could specify a set of default arguments for a given
subcommand. For example, 'svn diff' would default to 'svn diff -x
On 12/20/2010 05:28 PM, Hyrum K. Wright wrote:
> In issue #3765, I suggest the possibility of a CVS-style config file
> wherein a user could specify a set of default arguments for a given
> subcommand. For example, 'svn diff' would default to 'svn diff -x -p'
> if the config file had an entry for
On Mon, 2010-12-20, Danny Trebbien wrote:
> [[[
> Add a public API function, svn_subst_translate_string2(), an extension of
> svn_subst_translate_string(), that has two additional output parameters for
> determining whether re-encoding and/or line ending translation were performed.
[...]
Thanks, D
In issue #3765, I suggest the possibility of a CVS-style config file
wherein a user could specify a set of default arguments for a given
subcommand. For example, 'svn diff' would default to 'svn diff -x -p'
if the config file had an entry for such. Thinking this would be an
SMOP, I jumped in...on
On Mon, Dec 20, 2010 at 11:19 AM, Philip Martin
wrote:
> Johan Corveleyn writes:
>
>> This makes the diff algorithm another 10% - 15%
>> faster (granted, this was measured with my "extreme" testcase of a 1,5
>> Mb file (6 lines), of which most lines are identical
>> prefix/suffix).
>
> Can yo
On Mon, Dec 20, 2010 at 2:16 PM, Johan Corveleyn wrote:
> On Mon, Dec 20, 2010 at 11:03 AM, Julian Foad
> wrote:
>> On Mon, 2010-12-20, Johan Corveleyn wrote:
>>> New macro version (increment only, decrement is similar):
>>> [[[
>>> /* For all files in the FILE array, increment the curp pointer.
Philip Martin wrote on Mon, Dec 20, 2010 at 19:59:37 +:
> Daniel Shahaf writes:
>
> > Blair Zajac wrote on Mon, Dec 20, 2010 at 11:14:34 -0800:
> >>
> >> Shouldn't svn_repos_fs_commit_txn() always run the post-commit hook if
> >> new_rev is a valid rev?
> >>
> >
> > That matters when NEW_REV
Blair Zajac wrote on Mon, Dec 20, 2010 at 12:03:09 -0800:
>
> On Dec 20, 2010, at 11:48 AM, Daniel Shahaf wrote:
>
> > Blair Zajac wrote on Mon, Dec 20, 2010 at 11:14:34 -0800:
> >> The docs for svn_fs_commit_txn() for read:
> >>
> >> * @note Success or failure of the commit of @a txn is determi
On 12/20/2010 02:45 PM, Philip Martin wrote:
> cmpil...@apache.org writes:
>
>> Author: cmpilato
>> Date: Mon Dec 20 16:07:08 2010
>> New Revision: 1051164
>>
>> URL: http://svn.apache.org/viewvc?rev=1051164&view=rev
>> Log:
>> Another follow-up to r1050216.
>>
>> * subversion/libsvn_ra/util.c
>>
On Dec 20, 2010, at 11:48 AM, Daniel Shahaf wrote:
> Blair Zajac wrote on Mon, Dec 20, 2010 at 11:14:34 -0800:
>> The docs for svn_fs_commit_txn() for read:
>>
>> * @note Success or failure of the commit of @a txn is determined by
>> * examining the value of @a *new_rev upon this function's retu
Daniel Shahaf writes:
> Blair Zajac wrote on Mon, Dec 20, 2010 at 11:14:34 -0800:
>>
>> Shouldn't svn_repos_fs_commit_txn() always run the post-commit hook if
>> new_rev is a valid rev?
>>
>
> That matters when NEW_REV is a valid rev but there is a non-SVN_NO_ERROR
> return value. When can that
Blair Zajac wrote on Mon, Dec 20, 2010 at 11:14:34 -0800:
> The docs for svn_fs_commit_txn() for read:
>
> * @note Success or failure of the commit of @a txn is determined by
> * examining the value of @a *new_rev upon this function's return. If
> * the value is a valid revision number, the com
cmpil...@apache.org writes:
> Author: cmpilato
> Date: Mon Dec 20 16:07:08 2010
> New Revision: 1051164
>
> URL: http://svn.apache.org/viewvc?rev=1051164&view=rev
> Log:
> Another follow-up to r1050216.
>
> * subversion/libsvn_ra/util.c
> (svn_ra__release_operational_lock): Switch the sense of t
Blair Zajac writes:
> The docs for svn_fs_commit_txn() for read:
>
> * @note Success or failure of the commit of @a txn is determined by
> * examining the value of @a *new_rev upon this function's return. If
> * the value is a valid revision number, the commit was successful,
> * even though
On 12/20/2010 02:14 PM, Blair Zajac wrote:
> Shouldn't svn_repos_fs_commit_txn() always run the post-commit hook if
> new_rev is a valid rev?
That does seem reasonable, yes.
> BTW, we should have the docs for svn_fs_commit_txn mention that *new_rev is
> always modified, so the caller doesn't have
The docs for svn_fs_commit_txn() for read:
* @note Success or failure of the commit of @a txn is determined by
* examining the value of @a *new_rev upon this function's return. If
* the value is a valid revision number, the commit was successful,
* even though a n...@c NULL function return v
On Mon, Dec 20, 2010 at 12:31:55PM -0600, Hyrum K. Wright wrote:
> We got two sigs for each of Windows and Unix for 1.5.9, but the
> signing process has stalled from there. I'd still like to release
> this, if possible, but we should probably make a decision at some
> point.
I have run tests but
We got two sigs for each of Windows and Unix for 1.5.9, but the
signing process has stalled from there. I'd still like to release
this, if possible, but we should probably make a decision at some
point.
-Hyrum
On Thu, Dec 2, 2010 at 3:55 PM, Hyrum K. Wright
wrote:
> 1.5.9 tarballs are up for te
I'm working towards cleaning up the pristine store automatically.
Although not strictly necessary, I think it will be helpful if a
pristine text checksum in the DB shall be guaranteed always to reference
a pristine text that is currently in the store. In support of this
goal, the current patch en
C. Michael Pilato wrote on Mon, Dec 20, 2010 at 11:04:04 -0500:
> On 12/18/2010 04:29 PM, Daniel Shahaf wrote:
> > cmpil...@apache.org wrote on Thu, Dec 16, 2010 at 23:10:10 -:
>
> [...]
>
> >> * subversion/libsvn_ra/util.c
> >> (is_atomicity_error): Moved here from svnsync/main.c.
> >> (
On 12/18/2010 04:03 PM, Daniel Shahaf wrote:
> cmpil...@apache.org wrote on Wed, Dec 15, 2010 at 17:24:17 -:
>> @@ -947,14 +953,19 @@ subcommand_load(apr_getopt_t *os, void *
>> + if (err && err->apr_err == SVN_ERR_BAD_PROPERTY_VALUE)
>> +return svn_error_quick_wrap(err,
>> +
Hi Kevin.
Thanks for contributing this bug fix.
'@' is called an 'at' sign; '&' is called an ampersand.
Unfortunately your patch didn't reach the mailing list, probably because
the mailing list strips attachments that it doesn't recognize as a plain
text MIME type. You could try renaming it as
On 12/18/2010 04:29 PM, Daniel Shahaf wrote:
> cmpil...@apache.org wrote on Thu, Dec 16, 2010 at 23:10:10 -:
[...]
>> * subversion/libsvn_ra/util.c
>> (is_atomicity_error): Moved here from svnsync/main.c.
>> (svn_ra__release_operational_lock): New, abstracted from
>> svnsync/main.c:m
Danny Trebbien wrote:
> >> Hi Danny. Please could you enhance your tests so that they can detect
> >> this error (so that they will fail if this error is present).
> >
> > Sometimes I should use more words.
> >
> > What I meant to say is: I'm trying to devote as much of my time as
> > possible to
I stumbled across a bug in svn_load_dirs.pl when importing paths with an
ampersand character. Anything after the final ampersand in a path gets
interpreted as a peg revision during the add phase, so the affected files
don't get imported and the sanity check at the end fails.
I have attached a patc
>> Hi Danny. Please could you enhance your tests so that they can detect
>> this error (so that they will fail if this error is present).
>
> Sometimes I should use more words.
>
> What I meant to say is: I'm trying to devote as much of my time as
> possible to other things (WC-NG specifically) so
On Mon, 2010-12-20 at 10:11 +, Julian Foad wrote:
> On Sun, 2010-12-19 at 16:22 -0800, Danny Trebbien wrote:
> > Branko Čibej xbc.nu> writes:
> > > > Hi Daniel.
> > > >
> > > > I haven't looked at your patch v5 yet, because this Git diff doesn't
> > > > look quite right. How will this memcmp
On Mon, Dec 20, 2010 at 11:03 AM, Julian Foad wrote:
> On Mon, 2010-12-20, Johan Corveleyn wrote:
>> New macro version (increment only, decrement is similar):
>> [[[
>> /* For all files in the FILE array, increment the curp pointer. If a file
>> * points before the beginning of file, let it poin
Re:
* "svn info ^/b" -> "Not a valid URL"; should be "path '/b' not found
in revision REV"?
On Wed, 2010-12-08, Noorul Islam K M wrote:
[...]
> One of the solution that you suggested was to keep what the existing
> code is doing but saying something more helpful than "Not a valid
> URL". I thoug
On Mon, 2010-12-13, Noorul Islam K M wrote:
> Julian Foad writes:
> >
> > * "svn mv ^/ ^/" -> "Cannot move path
> > 'https:/svn.apache.org/repos/asf' into itself"; should not print the URL
> > as if it's a local path.
>
> Attached is the patch which improves error message displayed.
> [[[
> Ma
Johan Corveleyn writes:
> This makes the diff algorithm another 10% - 15%
> faster (granted, this was measured with my "extreme" testcase of a 1,5
> Mb file (6 lines), of which most lines are identical
> prefix/suffix).
Can you provide a test script? Or decribe the test more fully, please.
On Sun, 2010-12-19 at 16:22 -0800, Danny Trebbien wrote:
> Branko Čibej xbc.nu> writes:
> > > Hi Daniel.
> > >
> > > I haven't looked at your patch v5 yet, because this Git diff doesn't
> > > look quite right. How will this memcmp expression work properly if the
> > > two strings being compared a
On Mon, 2010-12-20, Johan Corveleyn wrote:
> New macro version (increment only, decrement is similar):
> [[[
> /* For all files in the FILE array, increment the curp pointer. If a file
> * points before the beginning of file, let it point at the first byte again.
> * If the end of the current ch
34 matches
Mail list logo
