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
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
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
>>
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
>
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
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
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
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
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
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
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
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
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
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
(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
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
>
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
> 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: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
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
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: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
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: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 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 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
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
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
On Tue, Dec 4, 2012 at 9:21 AM, Julian Foad wrote:
>> $ svn mergeinfo .
>> youngest last repos.
>> commonfull tip ofpath of
>> ancestor mergebranchbranch
>>
>> 14169441416945
>> | |
>> ---| |
Mark Phippard wrote:
>
> $ svn mergeinfo .
> youngest last repos.
> common full tip of path of
> ancestor merge branch branch
>
> 1416944 1416945
> | |
> ---| | subversion/branches/fsfs-form
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.
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
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 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
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
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
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
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
38 matches
Mail list logo
