On 28.08.2010 02:37, Stefan Sperling wrote:
> On Fri, Aug 27, 2010 at 01:20:31PM -0400, Bob Archer wrote:
>> Or, if not, the user can do a new checkout, and then use a compare
>> tool to apply your pending changes to your new WC. This means, don't
>> auto-update a WC that has pending changes in it
On Fri, Aug 27, 2010 at 01:20:31PM -0400, Bob Archer wrote:
> Or, if not, the user can do a new checkout, and then use a compare
> tool to apply your pending changes to your new WC. This means, don't
> auto-update a WC that has pending changes in it.
There won't be any auto-update, I think. The pl
I just noticed that the "entries-dump" test helper program can abort
with
/home/julianfoad/src/subversion-p/subversion/libsvn_subr/io.c:1933:
(apr_err=235000)
svn: In file
'/home/julianfoad/src/subversion-p/subversion/libsvn_wc/wc_db.c' line
522: assertion failed ((pdh)->wcroot != NULL && (pdh)->w
> On Fri, Aug 27, 2010 at 05:54:38PM +0100, Julian Foad wrote:
> > The trouble is, people often won't find out until some time after
> > they've upgraded, especially if it's a WC they aren't working on
> at the
> > moment and they try to come back to work on it some weeks later.
> And
> > for most
On Fri, Aug 27, 2010 at 05:54:38PM +0100, Julian Foad wrote:
> The trouble is, people often won't find out until some time after
> they've upgraded, especially if it's a WC they aren't working on at the
> moment and they try to come back to work on it some weeks later. And
> for most people un-upg
On Fri, 2010-08-27 at 12:46 -0400, Hyrum K. Wright wrote:
> On Fri, Aug 27, 2010 at 12:32 PM, Stefan Sperling wrote:
> > On Fri, Aug 27, 2010 at 12:03:04PM -0400, Bob Archer wrote:
> >> I'm just talking as a user here... and not an svn dev... but do you
> >> really need to spend time on a 1.6 to 1
On Fri, Aug 27, 2010 at 12:32 PM, Stefan Sperling wrote:
> On Fri, Aug 27, 2010 at 12:03:04PM -0400, Bob Archer wrote:
>> I'm just talking as a user here... and not an svn dev... but do you
>> really need to spend time on a 1.6 to 1.7 WC upgrade? Why not just
>> have 1.7 not work with 1.7 WCs and
I (Julian Foad) wrote:
> > On Aug 27, 2010 11:33 AM, "Julian Foad" wrote:
> > > In single-DB world, the WC generated in merge_tests.py 16, a directory
> > > 'A/B/F/Q' has been deleted from disk without informing Subversion, so
> > > its status is 'missing'.
> > >
> > > Look at the difference betwe
> Back up a step. *What* data do you need to query? Maybe there is a
> more
> direct solution.
>
> I very much dislike a special mode for wc_db. It just screams
> "hack".
>
> On Aug 27, 2010 10:07 AM, "Philip Martin"
>
> wrote:
> > "Bert Huijben" writes:
> >
> >> I really think that it is much
Recurse. Show all the info.
On Aug 27, 2010 11:33 AM, "Julian Foad" wrote:
> In single-DB world, the WC generated in merge_tests.py 16, a directory
> 'A/B/F/Q' has been deleted from disk without informing Subversion, so
> its status is 'missing'.
>
> Look at the difference between these two "svn
In single-DB world, the WC generated in merge_tests.py 16, a directory
'A/B/F/Q' has been deleted from disk without informing Subversion, so
its status is 'missing'.
Look at the difference between these two "svn status" runs on it:
$ svn st A/B/F -vu
!22 jrandom A/B/F
> On Aug 27, 2010 11:33 AM, "Julian Foad" wrote:
> > In single-DB world, the WC generated in merge_tests.py 16, a directory
> > 'A/B/F/Q' has been deleted from disk without informing Subversion, so
> > its status is 'missing'.
> >
> > Look at the difference between these two "svn status" runs on i
On 27.08.2010 17:32, Julian Foad wrote:
In single-DB world, the WC generated in merge_tests.py 16, a directory
'A/B/F/Q' has been deleted from disk without informing Subversion, so
its status is 'missing'.
Look at the difference between these two "svn status" runs on it:
$ svn st A/B/F -vu
!
On Fri, Aug 27, 2010 at 12:03:04PM -0400, Bob Archer wrote:
> I'm just talking as a user here... and not an svn dev... but do you
> really need to spend time on a 1.6 to 1.7 WC upgrade? Why not just
> have 1.7 not work with 1.7 WCs and tell the users they need to do a
> new checkout with 1.7. I mea
Back up a step. *What* data do you need to query? Maybe there is a more
direct solution.
I very much dislike a special mode for wc_db. It just screams "hack".
On Aug 27, 2010 10:07 AM, "Philip Martin"
wrote:
> "Bert Huijben" writes:
>
>> I really think that it is much easier to just walk the en
Greg Stein writes:
> Back up a step. *What* data do you need to query? Maybe there is a more
> direct solution.
Upgrade calls _scan_addition on the parent when writing a node, see
entries.c:write_entry.
> I very much dislike a special mode for wc_db. It just screams "hack".
If I put the new da
"Bert Huijben" writes:
> I really think that it is much easier to just walk the entries files using
> an old style-lock, constructing a new sqlite db 'upgrade.db' somewhere
> outside the normal location using upgrade specific code.
That might be another way to do it. If we construct a temporary
"Bert Huijben" writes:
> In case of a delete of copy you can have
>
> BASE normal (checked out N levels up)
> NODE_DATA normal (descendant of copy 2 levels up)
> NODE_DATA normal (child of copy 1 level up)
> WORKING: deleted (node itself)
>
> _read_info() will give you the information from workin
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: vrijdag 27 augustus 2010 14:57
> To: Bert Huijben
> Cc: 'Bert Huijben'; 'Greg Stein'; dev@subversion.apache.org
> Subject: Re: Two svn_wc__db_t for single-db upgrade
>
> "Bert Huijben" writes:
>
> >
"Bert Huijben" writes:
> But even in that case there can be different information in the parent stub
> and the child directory itself.
That's why I want to use the database.
>
>> > So you are suggesting that we change the DB API's to provide this
>> > information (or keep providing this multi-d
There's been no activity on the atomic-revprop branch on the last few
weeks. I haven't had time yet to work on the ra_dav error chain
marshalling (via the 207 XML parsers in ra_serf/ra_neon). Once that's
done (presumably on trunk), the final svnsync patch can be applied and
the branch merged.
I'
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: vrijdag 27 augustus 2010 11:50
> To: Bert Huijben
> Cc: 'Greg Stein'; dev@subversion.apache.org
> Subject: Re: Two svn_wc__db_t for single-db upgrade
>
> "Bert Huijben" writes:
>
> > The hard cases,
"Bert Huijben" writes:
> The hard cases, like missing and obstructions of metadata are not handled
> and cannot be handled by the single-db WC-DB api as these cannot occur there
> . (There are no tests for this, and anything that looks like a test for this
> is disabled for some 4th tree reason).
23 matches
Mail list logo