On Thu, Apr 18, 2013 at 8:53 AM, Roderich Schupp
wrote:
> Here's a small extension
Forgot to add the patch...
perl-bindings.patch
Description: Binary data
On Tue, Apr 16, 2013 at 6:15 PM, Philip Martin
wrote:
> I've applied your patch in r1468487, thanks!
Thanks. Here's a small extension: add an in typemap for apr_hash_t *PROPHASH.
This will enable the use of many non-deprecated methods in libsvn_client, e.g.
all with parameters of apr_hash_t *revp
17 apr 2013 kl. 00.39 skrev Daniel Shahaf:
Nice. I suppose that means we now have a bunch of places where _()
should be added --- such as svn_cl__info_print_time(). I am not quite
sure how to find all of them, other than by using a finished
translation
and then looking for English or mis-pu
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
On 17.04.2013 21:01, Daniel Shahaf wrote:
> Branko Čibej wrote on Wed, Apr 17, 2013 at 07:14:53 +0200:
>> The --config-dir option is IMO problematic for this since you'd have to
>> use the SVN command-line to initialize the credentials store -- the
>> format is such that I'd not recommend editing t
Branko Čibej wrote on Wed, Apr 17, 2013 at 07:14:53 +0200:
> The --config-dir option is IMO problematic for this since you'd have to
> use the SVN command-line to initialize the credentials store -- the
> format is such that I'd not recommend editing the auth store manually.
>
Manually? Of cours
On 04/17/2013 11:32 AM, Philip Martin wrote:
> "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 addition.
>>
>> Y
And both merge and patch allow adding directories with files inside...
And I have no idea how we can perform merge tracking on a merge
filtered by a change list... Merge the tree for each of the selected
files and ignore all the restructuring changes (adds/deletes)?
Bert From: Philip Martin
Sent
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 suggestion for patch/merge at least, so I've
raised:
h
"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 addition.
>
> You mean, perhaps, 'svn add --force -R' (or some other n
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 addition.
You mean, perhaps, 'svn add --force -R' (or some other non-empty depth).
But that marks files
"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 are part of the patch. Any plans to
>>> support this?
>>>
>>> (Should I be
"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
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-exist':
>> At revision 3
>>
>> Is it valid
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 are part of the patch. Any plans to
>> support this?
>>
>> (Should I be asking this on the dev list?)
>
> That
On Wed, Apr 17, 2013 at 3:21 PM, Bert Huijben wrote:
[...]
>
> Completely unrelated to this patch, but the usage of
> both info->props and info->dir->removed_props looks incorrect.
>
> Both props and removed_props are documented to be stored in
> the directory, but while removed_props is used that
"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 don't exist
>>
>> We allow the user to update a targe
> -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 don't exist
>
> We allow the user to update a target that is not present in the wo
> -Original Message-
> From: i...@apache.org [mailto:i...@apache.org]
> Sent: dinsdag 16 april 2013 16:36
> To: comm...@subversion.apache.org
> Subject: svn commit: r1468439 -
> /subversion/trunk/subversion/libsvn_ra_serf/update.c
>
> Author: ivan
> Date: Tue Apr 16 14:36:06 2013
> New R
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
21 matches
Mail list logo
