[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Work Queue doc strings and comments

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Fri, 19 Mar 2010 15:05:09 +0000

On Fri, 2010-03-19 at 10:49 -0400, Greg Stein wrote:
> On Fri, Mar 19, 2010 at 08:36, Julian Foad <julian.foad_at_wandisco.com> wrote:
> > I (Julian Foad) wrote:
> >> Are these doc strings and comments good?
> >
> > Sometimes I don't use enough words.
> >
> > I believe these additions are helpful, not so much because they provide
> > high density and hard-to-discover info (they don't, yet), but because
> > they provide a solid starting point for expanding as the functions
> > evolve to become more permanent and more complex. Having these as
> > starting points lowers the bar for adding documentation of any
> > non-trivial behaviours by indicating that some consideration has already
> > been made of the basics, and provides a quicker reference for the reader
> > than the alternative which was to search up and down the file for where
> > and how the function was used as a clue to its purpose and API.
> >
> > So all I'm asking is: is there anything incorrect or a very bad idea in
> > this patch?
> Nothing wrong with it,

Great. r925253.

> but I believe ALL of the current work items
> will disappear. As I've mentioned before, I think they are "backwards"
> from the desired design.

Yup, I've made a note of that and will try to assist with changing them
around. I'm absolutely fine with them all being deleted, comments and

> They are handy in terms of how loggy used to operate, but they do not
> make sense in our new database world.
> These work items perform DB work *and* file work. They should only
> perform file manipulations. Further, the work items should be
> installed as part of a DB transaction, within wc_db. For example, when
> code calls svn_wc__db_op_delete(), the database changes will be
> performed to delete the node(s) and work item(s) will be
> transactionally inserted to (then) make the filesystem reflect the
> state within the database (e.g remove prop files, the working copy
> file/dir, etc).

Great. That makes sense to me.

> So while there is nothing inherently bad/wrong with the comments, they
> don't help much.

They help me and others to understand the current state of play, not
much, I agree, but a bit.

> I'm about to start writing a "real" work item that will install a
> working copy file from its pristine text and its translation props.
> This is to correct a problem we have today where prop changes are
> being made and it tries to install the working copy file mid-state.
> The database is inconsistent, so the file-based work is seeing bad
> data. I need a work item to do the installation *after* the database
> state is stable. This same work item will be used to install files
> during checkout/update/switch and during post-commit, so it will be
> "real" and will be used for quite a bit of things.


> Once I finish that work item, if it is not documented to your desires,
> *then* I'd highly recommend jumping in and clarifying anything about
> it that bothers you.


- Julian
Received on 2010-03-19 16:05:45 CET

This is an archived mail posted to the Subversion Dev mailing list.