I'm investigating some problems around file externals, and ran into
this revision.
In the future: could you *please* try to break up large commits? This
revision is really large, and very difficult to provide proper review.
For example, the lock.c stuff could have been separate. And maybe the
int
On Tue, Apr 6, 2010 at 23:50, Greg Stein wrote:
>...
> I'm thinking that we add the following presence values (for
> WORKING_NODE.presence):
>
> "added": same as "normal" today. clarifies what this really means. we
> map this to status_added, so why not use this for the presence
> anyways? no need
There are five tests that are (now) broken because we cannot properly
represent a local-add within a copied-subtree. This wasn't a problem
in the past because we didn't have "proper" copyfrom handling. Once
that got fixed, it started to expose further problems...
The dev@ list has some discussion
On Wed, Apr 7, 2010 at 18:27, Julian Foad wrote:
> Greg Stein wrote:
>> Why do some names use text_base and others use pristine? Aren't those
>> the same thing?
>
> The ones using 'pristine' are the ones added by Hyrum's SVN_EXPERIMENTAL
> code, which, for the moment, run in parallel with the old
Greg Stein wrote:
> Why do some names use text_base and others use pristine? Aren't those
> the same thing?
The ones using 'pristine' are the ones added by Hyrum's SVN_EXPERIMENTAL
code, which, for the moment, run in parallel with the old ones, and then
later will replace the old ones. I haven't
On Wed, Apr 7, 2010 at 17:46, Bert Huijben wrote:
>...
>> Some of the common columns between BASE_NODE and WORKING_NODE move to
>> this new NODE_DATA table. I think they are:
>>
>> kind, [checksum], changed_*, properties
Note that I missed symlink_target above.
> I think you need some kind of
> -Original Message-
> From: Greg Stein [mailto:gst...@gmail.com]
> Sent: woensdag 7 april 2010 23:25
> To: Philip Martin
> Cc: dev@subversion.apache.org
> Subject: Re: fourth tree: "INHERITED" (was: wc-ng base/working nodes in
> a copied tree)
>
> After some further discussion on IRC, a
After some further discussion on IRC, and some thought...
I think this may be more of a representational problem, and might not
be a "true" fourth tree. Especially because supporting the revert
scenario actually implies N trees. Bert tried to describe this a while
back, but I didn't understand his
On Wed, Apr 7, 2010 at 04:52, Philip Martin wrote:
> Greg Stein writes:
>
>> I believe that we have the following operations:
>>
>> add: plain old add
>> add-within-copy/move: add within a subtree
>
> Those two are much the same. It makes little difference whether it's
> a plain add, an add with
On Wed, Apr 7, 2010 at 05:44, Philip Martin wrote:
> Greg Stein writes:
>
>> > Another problem is a copy of a mixed revision tree that includes base
>> > nodes that are not-present. In 1.6 we represent these as "fake"
>> > schedule deletes in the copy, so that they are explicitly deleted when
>>
On Wed, Apr 7, 2010 at 07:09, Philip Martin wrote:
> Greg Stein writes:
>
>> Excluded in the wc is just that. It does not mean "delete upon commit." We
>> have other statii to mean that.
>
> In 1.6 when we copy a tree containing deleted=true we mark the copied
> node so that it gets deleted upon
On Wed, Apr 7, 2010 at 10:08, wrote:
> Author: cmpilato
> Date: Wed Apr 7 14:08:12 2010
> New Revision: 931559
>
> URL: http://svn.apache.org/viewvc?rev=931559&view=rev
> Log:
> Add a --pre-1.7-compatible option to 'svnadmin create', with support
> for such in the repository and filesystem layer
Why do some names use text_base and others use pristine? Aren't those
the same thing?
On Wed, Apr 7, 2010 at 13:05, Julian Foad wrote:
> I'm going to apply this patch or something like it, tomorrow. The new
> names are very helpful in matching up text-base checksums to the
> corresponding (old,
I'm going to apply this patch or something like it, tomorrow. The new
names are very helpful in matching up text-base checksums to the
corresponding (old, current, new, copied, revert, ...) text base paths.
Trawling through all this is also helping me to understand the text-base
manipulations in
On Wed, Apr 7, 2010 at 3:05 AM, wrote:
> Author: gstein
> Date: Wed Apr 7 07:05:28 2010
> New Revision: 931449
>
> URL: http://svn.apache.org/viewvc?rev=931449&view=rev
> Log:
> Fix the inheritance handling for entry->copyfrom_*. The mapping code was
> not properly considering the copyfrom data
C. Michael Pilato wrote:
> Bert Huijben wrote:
>> Shouldn't we handle this in the specific RA layers instead of globally for
>> all ra-layers?
>>
>> That would allow removing the code for future code paths (like we did for
>> HTTPv2), while this code would hide the issues if we ever reintroduce t
On Wed, 2010-04-07 at 10:32 -0400, C. Michael Pilato wrote:
> Julian Foad wrote:
> > C. Michael Pilato wrote:
> >> Bert Huijben wrote:
> >>> Before r877014 we returned an error on paths as
> >>> "C:\path\that\is:invalid", but we didn't return an error on an equally
> >>> invalid path "//q:" (format
On Wed, Apr 7, 2010 at 9:46 AM, Bert Huijben wrote:
>> -Original Message-
>> From: Paul Burba [mailto:ptbu...@gmail.com]
>> Sent: woensdag 7 april 2010 15:27
>> To: Bert Huijben
>> Cc: Julian Foad; rhuij...@apache.org; dev@subversion.apache.org
>> Subject: Re: r877014 - on Windows, invalid
Julian Foad wrote:
> C. Michael Pilato wrote:
>> Bert Huijben wrote:
>>> Before r877014 we returned an error on paths as
>>> "C:\path\that\is:invalid", but we didn't return an error on an equally
>>> invalid path "//q:" (format is "//server/share" or "q:/") that happens to
>>> return ERROR_BAD_PATH
C. Michael Pilato wrote:
> Bert Huijben wrote:
> > Before r877014 we returned an error on paths as
> > "C:\path\that\is:invalid", but we didn't return an error on an equally
> > invalid path "//q:" (format is "//server/share" or "q:/") that happens to
> > return ERROR_BAD_PATHNAME instead of ERROR_
Bert Huijben wrote:
> Before r877014 we returned an error on paths as
> "C:\path\that\is:invalid", but we didn't return an error on an equally
> invalid path "//q:" (format is "//server/share" or "q:/") that happens to
> return ERROR_BAD_PATHNAME instead of ERROR_INVALID_NAME because it is
> handle
> -Original Message-
> From: Paul Burba [mailto:ptbu...@gmail.com]
> Sent: woensdag 7 april 2010 15:27
> To: Bert Huijben
> Cc: Julian Foad; rhuij...@apache.org; dev@subversion.apache.org
> Subject: Re: r877014 - on Windows, invalid path => svn_node_none [was: svn
> commit: r930333 - /sub
On Wed, Apr 7, 2010 at 5:09 AM, Bert Huijben wrote:
>
>
>> -Original Message-
>> From: Paul Burba [mailto:ptbu...@gmail.com]
>> Sent: dinsdag 6 april 2010 21:59
>> To: Julian Foad
>> Cc: rhuij...@apache.org; dev@subversion.apache.org
>> Subject: Re: r877014 - on Windows, invalid path => sv
Bert Huijben wrote:
>
>> -Original Message-
>> From: cmpil...@apache.org [mailto:cmpil...@apache.org]
>> Sent: dinsdag 6 april 2010 18:25
>> To: comm...@subversion.apache.org
>> Subject: svn commit: r931209 -
>> /subversion/trunk/subversion/libsvn_ra/ra_loader.c
>>
>> Author: cmpilato
>> D
> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: woensdag 7 april 2010 11:09
> To: 'Paul Burba'; 'Julian Foad'
> Cc: rhuij...@apache.org; dev@subversion.apache.org
> Subject: RE: r877014 - on Windows, invalid path => svn_node_none [was: svn
> commit: r930333 - /su
Greg Stein writes:
> Excluded in the wc is just that. It does not mean "delete upon commit." We
> have other statii to mean that.
In 1.6 when we copy a tree containing deleted=true we mark the copied
node so that it gets deleted upon commit. Are we going to change
that? If we mark the node exc
Excluded in the wc is just that. It does not mean "delete upon commit." We
have other statii to mean that.
Imagine a local-copy of a large tree, simul with excluding a large portion
so that u don't have to keep/copy as much locally. That doesn't mean
"delete". It is simply an organizational mechan
Greg Stein writes:
> > Another problem is a copy of a mixed revision tree that includes base
> > nodes that are not-present. In 1.6 we represent these as "fake"
> > schedule deletes in the copy, so that they are explicitly deleted when
> > the copy is committed. This works but has problems, the
on phone, so this will be terse, but wanted you to consider: I'd thought
about the copy-of-not-present case, and think we should actually represent
those nodes as excluded.
Thoughts?
On Apr 7, 2010 4:52 AM, "Philip Martin" wrote:
Greg Stein writes:
> I believe that we have the following opera
> -Original Message-
> From: cmpil...@apache.org [mailto:cmpil...@apache.org]
> Sent: dinsdag 6 april 2010 18:25
> To: comm...@subversion.apache.org
> Subject: svn commit: r931209 -
> /subversion/trunk/subversion/libsvn_ra/ra_loader.c
>
> Author: cmpilato
> Date: Tue Apr 6 16:25:21 2010
> -Original Message-
> From: Paul Burba [mailto:ptbu...@gmail.com]
> Sent: dinsdag 6 april 2010 21:59
> To: Julian Foad
> Cc: rhuij...@apache.org; dev@subversion.apache.org
> Subject: Re: r877014 - on Windows, invalid path => svn_node_none [was: svn
> commit: r930333 - /subversion/branche
Greg Stein writes:
> I believe that we have the following operations:
>
> add: plain old add
> add-within-copy/move: add within a subtree
Those two are much the same. It makes little difference whether it's
a plain add, an add within an add or an add within a copy/move.
> replace: delete-base
32 matches
Mail list logo
