Peter Samuelson :
>
> [Eric S. Raymond]
> > 1. Add support to the client tools for shipping a FULLNAME field
> > mined from somewhere under ~/.subversion. Maybe the existing
> > username entry will do, maybe it won't - I see arguments both ways.
> > I don't care, we can fill in that detail later
Eric S. Raymond wrote on Tue, Dec 04, 2012 at 03:39:12 -0500:
> Contrast protocol D: the user sets *one* preference in *one* place.
> He's done, nobody else had to do any work, and the change is
> guaranteed to be reflected in all his future commits. No scaling
> problem here.
>
The scaling prob
Daniel Shahaf :
> Eric S. Raymond wrote on Tue, Dec 04, 2012 at 03:39:12 -0500:
> > Contrast protocol D: the user sets *one* preference in *one* place.
> > He's done, nobody else had to do any work, and the change is
> > guaranteed to be reflected in all his future commits. No scaling
> > problem
On 04.12.2012 11:08, Eric S. Raymond wrote:
> Daniel Shahaf :
>> Eric S. Raymond wrote on Tue, Dec 04, 2012 at 03:39:12 -0500:
>>> Contrast protocol D: the user sets *one* preference in *one* place.
>>> He's done, nobody else had to do any work, and the change is
>>> guaranteed to be reflected in a
On Tue, Dec 4, 2012 at 3:39 AM, Eric S. Raymond wrote:
> Peter Samuelson :
>>
>> [Eric S. Raymond]
>> > 1. Add support to the client tools for shipping a FULLNAME field
>> > mined from somewhere under ~/.subversion. Maybe the existing
>> > username entry will do, maybe it won't - I see arguments
Hyrum K Wright wrote:
> 'svn merge' appears to hang when running a simple merge:
>
> [[[
> $ svnd merge ^/subversion/trunk/
> ^Csubversion/svn/util.c:913: (apr_err=4)
> subversion/svn/merge-cmd.c:163: (apr_err=4)
> subversion/libsvn_client/merge.c:11856: (apr_err=4)
> subversion/libsvn_client/mer
On Mon, Dec 3, 2012 at 9:23 PM, Hyrum K Wright wrote:
> 'svn merge' appears to hang when running a simple merge:
I just tried it on one of our branches and did not see the problem. I
started getting response pretty immediately. Here is transcript:
$ svn mergeinfo .
youngest last
I have a working copy created like this:
$ svn co --depth=immediates http://svn.apache.org/repos/asf/subversion
$ svn up --set-depth=infinity subversion/trunk
$ svn up --set-depth=immediates subversion/branches
$ svn up --set-depth=infinity subversion/branches/fsfs-format7
This all worked fine.
Mark Phippard wrote:
>
> $ svn mergeinfo .
> youngest last repos.
> common full tip of path of
> ancestor merge branch branch
>
> 1416944 1416945
> | |
> ---| | subversion/branches/fsfs-form
On Tue, Dec 4, 2012 at 9:21 AM, Julian Foad wrote:
>> $ svn mergeinfo .
>> youngest last repos.
>> commonfull tip ofpath of
>> ancestor mergebranchbranch
>>
>> 14169441416945
>> | |
>> ---| |
Hi,
Having started searching for structs which need typemaps to be generated
for swig-py i came across the dire need for subversion to invlude a proper
documentation of the structs which are included in the header files in
(trunk/subversion/include). Many of these structs having typemaps generated
Mark Phippard writes:
> I have a working copy created like this:
>
> $ svn co --depth=immediates http://svn.apache.org/repos/asf/subversion
> $ svn up --set-depth=infinity subversion/trunk
> $ svn up --set-depth=immediates subversion/branches
> $ svn up --set-depth=infinity subversion/branches/fs
On Tue, Dec 4, 2012 at 9:57 AM, Philip Martin
wrote:
> Mark Phippard writes:
>
>> I have a working copy created like this:
>>
>> $ svn co --depth=immediates http://svn.apache.org/repos/asf/subversion
>> $ svn up --set-depth=infinity subversion/trunk
>> $ svn up --set-depth=immediates subversion/b
On Tue, Dec 4, 2012 at 8:53 AM, Julian Foad wrote:
> Hyrum K Wright wrote:
>
> > 'svn merge' appears to hang when running a simple merge:
> >
> > [[[
> > $ svnd merge ^/subversion/trunk/
> > ^Csubversion/svn/util.c:913: (apr_err=4)
> > subversion/svn/merge-cmd.c:163: (apr_err=4)
> > subversion/lib
On Tue, Dec 4, 2012 at 10:05 AM, Hyrum K Wright wrote:
>> For your particular case, can you tell me what branch at what revision
>> your merge target was?
>
>
> The merge target was the ev2-export branch, which was probably most recently
> merged around 2-3 weeks ago, so it's not incredibly out-o
On Tue, Dec 4, 2012 at 10:14 AM, Mark Phippard wrote:
> On Tue, Dec 4, 2012 at 10:05 AM, Hyrum K Wright wrote:
>
>>> For your particular case, can you tell me what branch at what revision
>>> your merge target was?
>>
>>
>> The merge target was the ev2-export branch, which was probably most recen
On Tue, Dec 4, 2012 at 10:15 AM, Mark Phippard wrote:
> On Tue, Dec 4, 2012 at 10:14 AM, Mark Phippard wrote:
>> On Tue, Dec 4, 2012 at 10:05 AM, Hyrum K Wright
>> wrote:
>>
For your particular case, can you tell me what branch at what revision
your merge target was?
>>>
>>>
>>> The m
Mark Phippard writes:
> On Tue, Dec 4, 2012 at 10:05 AM, Hyrum K Wright wrote:
>
>>> For your particular case, can you tell me what branch at what revision
>>> your merge target was?
>>
>>
>> The merge target was the ev2-export branch, which was probably most recently
>> merged around 2-3 weeks
On Tue, Dec 4, 2012 at 10:36 AM, Philip Martin
wrote:
> Mark Phippard writes:
>
>> On Tue, Dec 4, 2012 at 10:05 AM, Hyrum K Wright
>> wrote:
>>
For your particular case, can you tell me what branch at what revision
your merge target was?
>>>
>>>
>>> The merge target was the ev2-export
On Tue, Dec 4, 2012 at 10:45 AM, Paul Burba wrote:
> On Tue, Dec 4, 2012 at 10:36 AM, Philip Martin
> wrote:
>> Mark Phippard writes:
>>
>>> On Tue, Dec 4, 2012 at 10:05 AM, Hyrum K Wright
>>> wrote:
>>>
> For your particular case, can you tell me what branch at what revision
> your me
> Mark Phippard wrote:
> Philip Martin wrote:
>> Mark Phippard writes:
>>> $ svn cleanup
>>> svn: E155004: Run 'svn cleanup' to remove locks (type 'svn
>>> help cleanup' for details)
>>> svn: E155004: Working copy
>>> '/Users/markphip/testing/subversion/branches/ev2-export' locked.
>>> sv
On Tue, Dec 4, 2012 at 10:56 AM, Julian Foad wrote:
> Ugh. It's important that we improve the error message. Please could you
> file an issue for that with milestone 1.8 unless it's going to get done today.
Done: http://subversion.tigris.org/issues/show_bug.cgi?id=4268
--
Thanks
Mark Phip
Ben Reser wrote:
> Eric S. Raymond wrote:
>> Peter Samuelson :
>>> [Eric S. Raymond]
>>> > 1. Add support to the client tools for shipping a FULLNAME field
>>> > mined from somewhere under ~/.subversion. Maybe the existing
>>> > username entry will do, maybe it won't - I see arguments both
>
(Sorry, still feeling a bit verbose.)
[Eric S. Raymond]
> 1. They have enough entropy that collisions aren't a practical problem.
> A human name alone does not. I'm excluding deliberate spoofing from
> the analysis because we now have enough experience with un-cryptosigned
> commits in DVCSes to
These six APIs all overlap in functionality:
1) svn_wc_check_root(*is_wcroot,*is_switched,*kind,...)
2 uses in 2 files
2) svn_wc__check_wc_root(*wc_root,*kind,*switched,...)
5 uses in 4 files
3) svn_wc__db_is_switched(*is_wcroot,*is_switched,*kind,...)
5 uses in 4 files
4) svn_wc_is
I (Julian Foad) wrote:
> These six APIs all overlap in functionality:
>
> 1) svn_wc_check_root(*is_wcroot,*is_switched,*kind,...)
> 2 uses in 2 files
>
> 2) svn_wc__check_wc_root(*wc_root,*kind,*switched,...)
> 5 uses in 4 files
>
> 3) svn_wc__db_is_switched(*is_wcroot,*is_switched,*kin
1 is new and should be the new public api (feel free to change it to a
better name and make 3 match it). 2 is the internal api from before the
introduction of 1 and 3.
4 is the old ill-defined public api and 5 the better defined variant. I
would make these new functions just check for ‘wcroot’, no
Note that we also have _get_wcroot functions since 1.7, which also have
the formerly known as ‘_strictly_’ behavior
. I think we should lose the strictly part of the name and make it easy to
detect switched paths (e.g. via the check api). Many callers accidentally
chose the wrong behavior in the p
Bert and others:
Would it be OK (performance-wise) to add optional 'properties' outputs to the
svn_wc__db_base_get_info()
svn_wc__db_depth_get_info()
svn_wc__db_read_info()
APIs, instead of the separate and irregular APIs we currently have for
specifically requesting the props? The point is t
Bert Huijben wrote:
> 1 is new and should be the new public api (feel free to change
> it to a better name and make 3 match it). 2 is the internal api
> from before the introduction of 1 and 3.
>
> 4 is the old ill-defined public api and 5 the better defined
> variant. I would make these new func
We already fetch the properties, but we just do an isnull check on those
columns, so it is just a case of adding yet another optional output
argument.
(I wouldn’t remove the old ones as parsing properties is not always cheap.
I know some specific users store kbytes of binary data in there and our
On Tue, Dec 4, 2012 at 10:48 AM, Paul Burba wrote:
> On Tue, Dec 4, 2012 at 10:45 AM, Paul Burba wrote:
>> On Tue, Dec 4, 2012 at 10:36 AM, Philip Martin
>> wrote:
>>> Mark Phippard writes:
>>>
On Tue, Dec 4, 2012 at 10:05 AM, Hyrum K Wright
wrote:
>> For your particular ca
On Wed, Dec 5, 2012 at 1:06 AM, Paul Burba wrote:
> On Tue, Dec 4, 2012 at 10:48 AM, Paul Burba wrote:
> > On Tue, Dec 4, 2012 at 10:45 AM, Paul Burba wrote:
> >> On Tue, Dec 4, 2012 at 10:36 AM, Philip Martin
> >> wrote:
> >>> Mark Phippard writes:
> >>>
> On Tue, Dec 4, 2012 at 10:05 A
Ben Reser :
> First of all the Ohloh problem has already been solved by Ohloh. You
> can claim your commits.
More pointless handwork. We ought to be designing *away* from this
sort of thing...
> 1) Some people may prefer not to use the same identity on different
> projects, even open source pro
Peter Samuelson :
>
> (Sorry, still feeling a bit verbose.)
Yeah, like *I'd* have any room to criticize on that score... :-)
> [Eric S. Raymond]
> > 1. They have enough entropy that collisions aren't a practical problem.
> > A human name alone does not. I'm excluding deliberate spoofing from
>
I (Julian Foad) wrote:
> Bert Huijben wrote:
>> 1 is new and should be the new public api (feel free to change
>> it to a better name and make 3 match it). 2 is the internal api
>> from before the introduction of 1 and 3.
>>
>> 4 is the old ill-defined public api and 5 the better defined
>>
On Tue, Dec 4, 2012 at 7:49 PM, wrote:
> Author: hwright
> Date: Wed Dec 5 00:49:22 2012
> New Revision: 1417252
>
> URL: http://svn.apache.org/viewvc?rev=1417252&view=rev
> Log:
> Manually migrate the Ev2 export implementation (in the case of recursive
> directory exports) from the ev2-export b
Eric S. Raymond wrote on Tue, Dec 04, 2012 at 19:54:17 -0500:
> Ben Reser :
> > As it stands the entire functioning of your proposed solution here
> > is that people always remember to configure their unique id.
> > I don't see that as particularly easier than what the situation is
> > now where yo
38 matches
Mail list logo
