Hi,
> Von: Johan Corveleyn [mailto:jcor...@gmail.com]
> On Wed, Jul 11, 2012 at 8:07 PM, Hyrum K Wright wrote:
> > On Wed, Jul 11, 2012 at 12:25 PM, Johan Corveleyn wrote:
> >> That's true, but one of the problems I'm trying to solve here is
> >> users having different clients on their system,
Hi,
> Von: Bert Huijben [mailto:b...@qqmail.nl]
> > From: Johan Corveleyn [mailto:jcor...@gmail.com]
> >
> > I'd like to continue this discussion a bit more, as there are still
> > some things lingering here ...
>
> > Also, as I said, an auto-upgrade needs at least:
> > - To be reversible (need d
On Wed, Jul 11, 2012 at 3:19 PM, Johan Corveleyn wrote:
> On Wed, Jul 11, 2012 at 8:07 PM, Hyrum K Wright wrote:
>> On Wed, Jul 11, 2012 at 12:25 PM, Johan Corveleyn wrote:
>>> On Wed, Jul 11, 2012 at 7:14 PM, Hyrum K Wright
>>> wrote:
On Wed, Jul 11, 2012 at 12:09 PM, Johan Corveleyn
>
On Wed, Jul 4, 2012 at 2:26 PM, Johan Corveleyn wrote:
> On Wed, Jul 4, 2012 at 2:11 PM, Vincent Lefevre
> wrote:
>> On 2012-07-04 13:58:50 +0200, Johan Corveleyn wrote:
>>> > The problem now is that the URL + the LastChangedRev together can
>>> > no longer identify the file, because the LastCha
On Wed, Jul 11, 2012 at 8:07 PM, Hyrum K Wright wrote:
> On Wed, Jul 11, 2012 at 12:25 PM, Johan Corveleyn wrote:
>> On Wed, Jul 11, 2012 at 7:14 PM, Hyrum K Wright
>> wrote:
>>> On Wed, Jul 11, 2012 at 12:09 PM, Johan Corveleyn wrote:
...
For instance, we could simply package two se
10 jul 2012 kl. 22.38 skrev Peter Samuelson:
Whatever it is in the data path that makes it slower, it probably is
not a fair comparison. Even though we normally don't want to do our
own fdatasync(), it is fair to consider the additional I/O load that
is
generated by Subversion operations. Th
On Wed, Jul 11, 2012 at 12:25 PM, Johan Corveleyn wrote:
> On Wed, Jul 11, 2012 at 7:14 PM, Hyrum K Wright wrote:
>> On Wed, Jul 11, 2012 at 12:09 PM, Johan Corveleyn wrote:
>>> ...
>>> For instance, we could simply package two set of binaries/libraries in
>>> one package (the 1.8.0 version toge
On Wed, Jul 11, 2012 at 7:14 PM, Hyrum K Wright wrote:
> On Wed, Jul 11, 2012 at 12:09 PM, Johan Corveleyn wrote:
>> ...
>> For instance, we could simply package two set of binaries/libraries in
>> one package (the 1.8.0 version together with 1.7.x (taken from the
>> corresponding tag)), and impl
On Wed, Jul 11, 2012 at 12:09 PM, Johan Corveleyn wrote:
> ...
> For instance, we could simply package two set of binaries/libraries in
> one package (the 1.8.0 version together with 1.7.x (taken from the
> corresponding tag)), and implement a main wrapper that delegates
> everything to the approp
On Wed, Jul 11, 2012 at 5:29 PM, Mark Phippard wrote:
> On Wed, Jul 11, 2012 at 8:21 AM, Johan Corveleyn wrote:
>>
>> On Wed, Jul 11, 2012 at 4:23 PM, C. Michael Pilato
>> wrote:
>> ...
>> > That said, I'm not really in favor of us maintaining multiple codepaths
>> > (based on WC version) in the
C. Michael Pilato wrote:
> On 07/11/2012 09:12 AM, Branko Čibej wrote:
>> That is correct. Essentially, not only does the server have to know
>> about and correctly record renames; the rename operations in the update
>> (or merge) editor drive need to happen in the correct order so that they
>>
On Wed, Jul 11, 2012 at 8:21 AM, Johan Corveleyn wrote:
> On Wed, Jul 11, 2012 at 4:23 PM, C. Michael Pilato
> wrote:
> ...
> > That said, I'm not really in favor of us maintaining multiple codepaths
> > (based on WC version) in the client. I just don't see the cost
> justifying
> > the benefit
On Wed, Jul 11, 2012 at 4:23 PM, C. Michael Pilato wrote:
...
> That said, I'm not really in favor of us maintaining multiple codepaths
> (based on WC version) in the client. I just don't see the cost justifying
> the benefit. I mean, it makes sense to do so in the repositories as we do
> today,
On Wed, Jul 11, 2012 at 4:45 PM, Bert Huijben wrote:
>
>
>> -Original Message-
>> From: Johan Corveleyn [mailto:jcor...@gmail.com]
>> Sent: woensdag 11 juli 2012 15:51
>> To: Greg Stein
>> Cc: dev@subversion.apache.org
>> Subject: Re: Format bump for 1.8?
>>
>> I'd like to continue this di
> -Original Message-
> From: C. Michael Pilato [mailto:cmpil...@collab.net]
> Sent: woensdag 11 juli 2012 16:39
> To: Bert Huijben
> Cc: 'Hyrum K Wright'; 'Johan Corveleyn'; 'Greg Stein';
> dev@subversion.apache.org
> Subject: Re: Format bump for 1.8?
>
> On 07/11/2012 10:37 AM, Bert Hui
> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: woensdag 11 juli 2012 15:51
> To: Greg Stein
> Cc: dev@subversion.apache.org
> Subject: Re: Format bump for 1.8?
>
> I'd like to continue this discussion a bit more, as there are still
> some things lingering
On 07/11/2012 10:37 AM, Bert Huijben wrote:
> Are there any other changes waiting for a format bump right now?
I can't recall now: did the new MD5 index into the pristines require a
format bump?
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
signa
> -Original Message-
> From: Hyrum K Wright [mailto:hy...@hyrumwright.org]
> Sent: woensdag 11 juli 2012 16:27
> To: C. Michael Pilato
> Cc: Johan Corveleyn; Greg Stein; dev@subversion.apache.org
> Subject: Re: Format bump for 1.8?
>
> I agree with Mike on all of the above.
>
> > I actu
On Wed, Jul 11, 2012 at 7:23 AM, C. Michael Pilato wrote:
> I actually feel like the 1.7 situation was the best we've had to date:
> restrictive WC format client support, an explicit upgrade step, minimal
> surprises.
>
Agreed. I think the only problem with the 1.7 upgrade was that it was the
f
On Wed, Jul 11, 2012 at 9:23 AM, C. Michael Pilato wrote:
> On 07/11/2012 09:50 AM, Johan Corveleyn wrote:
>> Yes, I agree we'd have to make it clear in our docs that feature X
>> depends on working copy format Y. That's an additional effort, yes.
>> But for the book or the FAQ it's not a lot diff
On 07/11/2012 09:50 AM, Johan Corveleyn wrote:
> Yes, I agree we'd have to make it clear in our docs that feature X
> depends on working copy format Y. That's an additional effort, yes.
> But for the book or the FAQ it's not a lot different from phrases
> where they now say: "If you've got Subversi
On 07/11/2012 09:12 AM, Branko Čibej wrote:
> That is correct. Essentially, not only does the server have to know
> about and correctly record renames; the rename operations in the update
> (or merge) editor drive need to happen in the correct order so that they
> can be reflected in the working co
I'd like to continue this discussion a bit more, as there are still
some things lingering here ...
On Thu, Jun 28, 2012 at 1:32 AM, Greg Stein wrote:
> On Wed, Jun 27, 2012 at 7:19 PM, Johan Corveleyn wrote:
>> On Tue, Jun 26, 2012 at 10:51 AM, Stefan Sperling wrote:
>>> On Mon, Jun 25, 2012 at
(I'll answer in more detail later, just quick points for now)
Robert Muir wrote on Tue, Jul 10, 2012 at 08:24:55 -0400:
> On Tue, Jul 10, 2012 at 4:43 AM, Daniel Shahaf
> wrote:
> > Robert:
> >
> > How did you commit r1356317? (the import of the api-4_0_0_ALPHA docs to
> > the CMS) Did you get
Johan Corveleyn wrote on Tue, Jul 10, 2012 at 21:54:39 +0200:
> On Tue, Jul 10, 2012 at 2:43 PM, Robert Muir wrote:
> > On Tue, Jul 10, 2012 at 2:17 AM, Trent Nelson wrote:
> >>
> >> I've also never come across this in the wild. We should definitely ping
> >> `rmuir` to find out how he committed
On Wed, Jul 11, 2012 at 7:44 AM, Julian Foad wrote:
> Branko Čibej wrote:
>> On 10.07.2012 23:40, Julian Foad wrote:
>>> I think the essence of this line of thought is:
>
>>>
>>> We set up all of the possible mergeinfo scenarios, and we see what 'merge'
>>> does, and we see what 1.7 'merge --rein
On 11.07.2012 13:43, Johan Corveleyn wrote:
> On Sun, Jun 24, 2012 at 3:51 PM, Julian Foad
> wrote:
> ...
>> I just want to say: I'm not at all demanding we break backward
>> compatibility. Sorry if it sounded like it. I'm just saying that we're
>> proposing to change the behaviour of the plain
On Sun, Jun 24, 2012 at 3:51 PM, Julian Foad wrote:
...
> I just want to say: I'm not at all demanding we break backward
> compatibility. Sorry if it sounded like it. I'm just saying that we're
> proposing to change the behaviour of the plain merge command, and in doing
> that we need to work ou
On 11.07.2012 12:44, Julian Foad wrote:
> Branko Čibej wrote:
>> Am I correct in assuming that most of this discussion is a consequence
>> of the current implementation of mergeinfo inheritance? I.e., that there
>> are a certain number of hoops one needs to jump through in order to
>> determine whi
Johan Corveleyn wrote:
> On Wed, Jul 11, 2012 at 6:19 AM, Branko Čibej wrote:
>> Am I correct in assuming that most of this discussion is a consequence
>> of the current implementation of mergeinfo inheritance? I.e., that there
>> are a certain number of hoops one needs to jump through in order
Branko Čibej wrote:
> On 10.07.2012 23:40, Julian Foad wrote:
>> I think the essence of this line of thought is:
>>
>> We set up all of the possible mergeinfo scenarios, and we see what 'merge'
>> does, and we see what 1.7 'merge --reintegrate' does, and we debate what
>> cases are 'supported' v
On Wed, Jul 11, 2012 at 6:19 AM, Branko Čibej wrote:
> On 10.07.2012 23:40, Julian Foad wrote:
>> I think the essence of this line of thought is:
>>
>> We set up all of the possible mergeinfo scenarios, and we see what 'merge'
>> does, and we see what 1.7 'merge --reintegrate' does, and we debate
32 matches
Mail list logo
