Daniel Rall <dlr@finemaltcoding.com> writes:
> Should the STACK file still be installed by RPM? The .spec file was
> just modified to no longer install it per its removal yesterday.
Nah, wouldn't bother. I have a feeling the STACK file will go away
soon; we should sweep it for forgotten tasks, make issues out of them,
and then make it go away (unless someone particularly wants to keep
it). It has not generally been up-to-date.
-Karl
> kfogel@tigris.org writes:
>
> > Author: kfogel
> > Date: 2001-12-06 19:05 GMT
> > New Revision: 617
> >
> > Added:
> > trunk/notes/STACK
> > Log:
> > * STACK: In revision 596, Greg Stein meant to move STACK from the top
> > level to here, but only the delete succeeded -- the add never
> > happened (hmm). Anyway, here it is, albeit with no copy history.
> >
> >
> > Added: trunk/notes/STACK
> > ==============================================================================
> > --- OLD/trunk/notes/STACK Thu Dec 6 13:05:36 2001
> > +++ NEW/trunk/notes/STACK Thu Dec 6 13:05:36 2001
> > @@ -0,0 +1,397 @@
> > + -*-text-*-
> > +
> > +If you're looking for a task to take on, please see the TASKS file.
> > +
> > +This file merely lists immediate, short-term (next few days) stuff on
> > +people's stacks. It may make reference to phone conversations and
> > +private emails, so a given item might not make much sense unless one
> > +is familiar with its out-of-band context. We keep this file under
> > +version control mainly for convenience -- feel free to add your own
> > +short-term tasks to it, if that's helpful.
> > +
> > +------------------------------------------------------------------------
> > +
> > +General Problems (someone grab these):
> > +
> > + - updates (right now) don't bump the revision of every entry as
> > + they should; instead we're only bumping the changed entries.
> > +
> > + - unable to update specific targets right now; we need to
> > + distinguish between specific targets and general full recursive
> > + updates.
> > +
> > + - don't use stdio's BUFSIZ (portability?). define an SVN specific
> > + constant and use it throughout.
> > +
> > + - refactor client/main.c's cmdline handling and place it into
> > + libsvn_subr. use the new functions within svnadmin/main.c.
> > +
> > + - svn_string.c::svn_string_createf(): follow the comments about
> > + refactoring to prevent double memory usage
> > +
> > + - update authentication mechanisms so that multiple systems can be
> > + defined, and the client will choose the "best" one (given whatever
> > + consideration it chooses).
> > +
> > +Ben todo:
> > +
> > + - finish svn_fs_is_different, make status command use it.
> > +
> > +
> > +Karl:
> > +
> > + - Propagate changes down into libsvn_client. Currently, the client
> > + usually takes a `targets' list and iterates over it, invoking
> > + some libsvn_client routine each time. There are cases where the
> > + libsvn_client routine should get the target list directly and do
> > + the iteration internally, or even pass the list on down into
> > + libsvn_wc.
> > + - create .alt files instead of .rej for those that `patch' can't
> > + handle.
> > + - with Ben, review locking protocol in wc adm directories for sanity.
> > + - check apr_open calls, do they assume failure implies null handle?
> > + - fix working copy identification/allergy code
> > + - make sure type-changing replacements work right
> > +
> > +Ben and Karl (longer term):
> > +
> > + - revision numbers in URLs? Why are we depending on the implied
> > + `HEAD'?? Ben points out that this solves the "Where does the
> > + repos begin problem" too. :-)
> > +
> > + - xml dtd, for both xml deltas and wc formats
> > +
> > +Greg:
> > +
> > + - mod_dav_svn:
> > + - implement copy/move in the repos
> > +
> > + - liveprop hooks: rest of liveprops
> > + - what is missing?
> > + - what is needed for SVN vs DAV/DeltaV interop?
> > +
> > + - vsn hooks: any others for DAV/DeltaV interop?
> > +
> > + - version resource URL prep should look up the node
> > +
> > + - change the dav_svn_ prefix to ??? (svn_mod_dav_svn too long;
> > + svn_mds? svn_dav? leave it?
> > +
> > + - mod_dav:
> > + - switch property handling to buckets/brigades
> > + - switch dav_stream to buckets/brigades
> > + - complete the propdb API conversion (step 1; step 2 is the brigade
> > + thing above)
> > +
> > + M3 ITEMS:
> > + - VERSION stuff. VPATH builds.
> > + - cvs2svn
> > + - Python bindings
> > + - just enough for cvs2svn
> > + - the rest
> > + - DB_RUN_RECOVERY handling
> > + - pool review
> > +
> > + WHENEVER:
> > + - APR: move apr_copy_file() from SVN. and apr_append_file, etc.
> > + - security checks (e.g. system() usage in wc/get_editor)
> > +
> > +
> > +Joe:
> > + - implementing authentication callbacks for ra_dav/client layers
> > + [ still needed? maybe this could be client certs? ]
> > +
> > +
> > +Working Copy:
> > +
> > + TBDesigned:
> > + The WC will need to have some knowledge of "the repository"
> > + associated with any given resource. Given a working copy, the
> > + client cannot know whether a two URLs are within the same
> > + repository or not, so it doesn't know whether one or multiple
> > + commit sequences are required to commit the whole working copy.
> > +
> > + The RA layer (in conjunction with the server) will need to somehow
> > + tell the WC about the repository associated with a given directory
> > + (or long term, each file?). At commit time, the WC sorts out how
> > + many repositories are involved, and performs a commit per
> > + repository.
> > +
> > + [ We never really had a story for discriminating multiple
> > + repositories within a given WC. Stopping to think about it, it
> > + was just a hand-wave. Given the flexibility in URLs and virtual
> > + hosting on the server and whatnot, static analysis of a URL will
> > + never be sufficient, but the server can always state
> > + definitively the repository for any given resource. ]
> > +
> > +
> > +Filesystem:
> > +
> > + Anyone, WRT filesystem:
> > +
> > + We need a function that will remove the *first*, not the last,
> > + component from a path. We need this to support full-path lookups
> > + in the new FS interface, specifically, for open_path.
> > +
> > + Suggest something like this:
> > +
> > + int svn_path_first_component (const char **name,
> > + char **path,
> > + enum svn_path_style style);
> > +
> > + This would point *NAME to the first component in *PATH, and
> > + modify *PATH to split the first component off. Return 0 if *NAME
> > + is empty, otherwise 1. See the pseudocode in open_path in tree.c
> > + to see how this would be used.
> > +
> > +Changes to svn_delta_edit_fns_t:
> > +
> > + These are the summary emails Ben sent to the dev list (lightly
> > + edited), concerning changes proposed and accepted at the meetings
> > + in Chicago on January 14-16. A few of these are still being
> > + discussed on the list; see the "STATUS" lines for more.
> > +
> > + =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > + Change #6: Move textdeltas to the "other side" of the editor.
> > + STATUS: Being discussed on list; holding off on making this change.
> > + The Way It Works Now:
> > + The driver of an editor takes a source and target stream, puts them
> > + together via svn_txdelta() to produce a stream of "windows". The
> > + driver then pushes these windows at the editor's window-handler.
> > +
> > + Proposed Change:
> > + Move this process to the other side of the interface, into the
> > + editor implementation, giving the editor the power to deal with the
> > + source and target streams directly.
> > +
> > + Specifically:
> > + - remove the editor's apply_txdelta() routine
> > + - create two new routines:
> > + apply_delta (filebaton, [src_stream], target_stream)
> > + set_file_contents (filebaton, [src_stream], delta,
> > + enum delta_type)
> > +
> > + apply_delta() sends svndiff deltas.
> > + set_file_contents() can send plain text or other
> > + types.
> > +
> > + It becomes the obligation of the editor implementation to
> > + implement at least one of these two routines; if one
> > + routine is NULL, the driver must use the other.
> > +
> > + Rationale:
> > + It's too restrictive to force every editor implementation to accept
> > + and deal with small svndiff windows. For example: Greg Stein wants
> > + to send plain text while debugging his commit-editor and network
> > + layer. It's best to allow the RA layer to make it's own choice
> > + about how to break up the two streams most efficiently.
> > +
> > + The reason [src_stream] is optional is that it may be NULL; this
> > + presumably means that the editor already has access to the src
> > + stream.
> > +
> > + (Greg and Jim, did I get this explanation totally wrong? My notes
> > + here aren't perfectly clear. Please elaborate if you need to.)
> > +
> > + Problem:
> > + Editor composition becomes more difficult if we use streams. A
> > + window is a discrete chunk of data that can be used by several
> > + consumers, but streams are different: if consumer A reads some
> > + data off a stream, then when consumer B reads, she'll get
> > + different results. You'd have to design your streams in a funky
> > + way to make this not be a problem.
> > +
> > + In some circumstances, this isn't an issue. After all, usually
> > + a set of composed editors is a bunch of lightweight editors,
> > + that don't do much, surrounding a core editor that does the real
> > + work. For example, an editor that prints out filenames wrapped
> > + with an editor that actually updates those files. In such
> > + cases, the lightweight editor simply never reads data off the
> > + stream, so the core editor is not deprived of anything.
> > +
> > + But other editors (say, a commit guard?) might want to actually
> > + examine file data. That could have bad consequences if we
> > + switch from windows to streams.
> > +
> > + =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > + Change #7: New filesystem "copy" nodes (and renaming add_*() args)
> > + STATUS: Will be done by Brane, now that he's dug what this is all about.
> > + The Way It Works Now:
> > + When we copy (or move) a node in the filesystem, we're currently
> > + losing information about where it came from. Our "lazy cloning"
> > + model goes a long way, but in the end we get just a bunch of
> > + duplicated pointers to the same node revision numbers.
> > +
> > + E.g.: if a node A points to the same node revision that two others
> > + (B and C) point to, there's no way to know whether A was copied
> > + from B or C.
> > +
> > + Proposed Changes:
> > + 1. In the filesystem model, create a 3rd node type called a "copy"
> > + node. (This is in addition to our "file" and "dir" nodes.)
> > +
> > + A copy node contains a pointer to a revision and a path.
> > +
> > + When we create node B as a "copy" of node A, we create a new
> > + copy node. This copy node allows us to discover the proper
> > + node-revision, but it also tracks the history of the copy.
> > +
> > + 2. Remember that a copy command is really just an "add with
> > + history", and a move command is really just a "delete, followed
> > + by an add with history". Thus it's the *add* command, which,
> > + when given an ancestor path and revision, creates a copy node.
> > + (If there's no history given, then the add command creates a
> > + regular node.)
> > +
> > + For clarity sake, the history arguments to the editor's add()
> > + function should reflect this copying. Instead of
> > + "ancestor_path" and "ancestor_revision", we'd like to call the
> > + arguments "copyfrom_url" and "copyfrom_revision".
> > +
> > + Rationale:
> > + I think it's all been explained above. Other folks, feel free to
> > + add to this explanation.
> > +
> > +Anyone:
> > +
> > + These three mails between Greg Stein and Ben explain the issue:
> > +
> > + ----------------------------------------------------------------------
> > + From: Greg Stein <gstein@lyra.org>
> > + Subject: Re: CVS update: subversion/subversion/libsvn_ra_local \
> > + Makefile.am ra_local.h ra_plugin.c split_url.c
> > + To: dev@subversion.tigris.org
> > + Date: Fri, 9 Feb 2001 17:27:06 -0800
> > +
> > + On Sat, Feb 10, 2001 at 12:59:19AM -0000, sussman@tigris.org wrote:
> > + >...
> > + > @@ -283,7 +296,10 @@
> > + > apr_pool_t *pool,
> > + > const svn_ra_plugin_t **plugin)
> > + > {
> > + > - *plugin = ra_local_plugin;
> > + > + svn_ra_plugin_t *p = apr_pcalloc (pool, sizeof (*p));
> > + > + memcpy (p, &ra_local_plugin, sizeof (ra_local_plugin));
> > + > +
> > + > + *plugin = p;
> > +
> > + Overkill. Use:
> > +
> > + *plugin = &ra_local_plugin;
> > +
> > + > /* are we ever going to care about abi_version? */
> > +
> > + Yes.
> > +
> > + >... [ split_url ]
> > +
> > + This function would be a *lot* simpler, if you:
> > +
> > + 1) make a dup of the URL
> > + 2) strip the leading file:// portion (leaving "/abs/path/foo/bar")
> > + 3) loop:
> > + a) try to open FS with the path. succeed: break
> > + b) chop the last component off
> > + 4) fs_path is what remains, repos_path is &URL[strlen(fs_path) + 7]
> > + (the +7 is to account for "file://" at the start of the URL)
> > +
> > + The whole algorithm only requires one string dup to hold the shrinking path.
> > + stripping the leading "file://" is simply advancing string->data (we should
> > + have a utility function for this, because string->blocksize must shrink).
> > + The chopping just drops in '\0' into the dup'd path. The return is done by
> > + duplicating the input URL, or altering the input ->data and ->blocksize
> > + field values.
> > +
> > + And warning: I'm not sure whether a file URL is in "local" or "URL" style
> > + separators. Strictly speaking, our "URL style" is really "http scheme URL
> > + style". If the file URL uses "/" no matter what, then we would (strictly)
> > + need to convert the dup'd path (the fs_path) to local style before beginning
> > + the loop/test.
> > +
> > + Cheers,
> > + -g
> > + ----------------------------------------------------------------------
> > + From: Ben Collins-Sussman <sussman@newton.ch.collab.net>
> > + Subject: Re: CVS update: subversion/subversion/libsvn_ra_local \
> > + Makefile.am ra_local.h ra_plugin.c split_url.c
> > + To: Greg Stein <gstein@lyra.org>
> > + Cc: dev@subversion.tigris.org
> > + Date: 09 Feb 2001 20:06:42 -0600
> > +
> > + Greg Stein <gstein@lyra.org> writes:
> > +
> > + > Overkill. Use:
> > + >
> > + > *plugin = &ra_local_plugin;
> > + >
> > +
> > + Heh, sure. :)
> > + >
> > + > >... [ split_url ]
> > + >
> > + > This function would be a *lot* simpler, if you:
> > + >
> > + > 1) make a dup of the URL
> > + > 2) strip the leading file:// portion (leaving "/abs/path/foo/bar")
> > + > 3) loop:
> > + > a) try to open FS with the path. succeed: break
> > + > b) chop the last component off
> > + > 4) fs_path is what remains, repos_path is &URL[strlen(fs_path) + 7]
> > + > (the +7 is to account for "file://" at the start of the URL)
> > +
> > + Oh, this is the *easy* way, which I purposely avoided.
> > +
> > + I wanted to be "correct" by searching from the other direction,
> > + thereby always finding the repository with the shortest path, not the
> > + longest.
> > +
> > + Yes, I know, we agreed that we will never allow nested repositories.
> > + I guess I was being paranoid and trying to emulate Apache's search
> > + methods. :)
> > +
> > + Do you think it's worth re-writing?
> > +
> > + ----------------------------------------------------------------------
> > + From: Greg Stein <gstein@lyra.org>
> > + Subject: Re: CVS update: subversion/subversion/libsvn_ra_local \
> > + Makefile.am ra_local.h ra_plugin.c split_url.c
> > + To: dev@subversion.tigris.org
> > + Date: Fri, 9 Feb 2001 19:19:57 -0800
> > +
> > + On Fri, Feb 09, 2001 at 08:06:42PM -0600, Ben Collins-Sussman wrote:
> > + > Greg Stein <gstein@lyra.org> writes:
> > + >...
> > + > > >... [ split_url ]
> > + > >
> > + > > This function would be a *lot* simpler, if you:
> > + > >
> > + > > 1) make a dup of the URL
> > + > > 2) strip the leading file:// portion (leaving "/abs/path/foo/bar")
> > + > > 3) loop:
> > + > > a) try to open FS with the path. succeed: break
> > + > > b) chop the last component off
> > + > > 4) fs_path is what remains, repos_path is &URL[strlen(fs_path) + 7]
> > + > > (the +7 is to account for "file://" at the start of the URL)
> > + >
> > + > Oh, this is the *easy* way, which I purposely avoided.
> > + >
> > + > I wanted to be "correct" by searching from the other direction,
> > + > thereby always finding the repository with the shortest path, not the
> > + > longest.
> > +
> > + Ah. Right. Sorry...
> > +
> > + But still a simple change. Search from the left for '/'; replace with '\0';
> > + test for an FS; if not found, then put the '/' back and look for the next
> > + '/' (repeat).
> > +
> > + >...
> > + > Do you think it's worth re-writing?
> > +
> > + Yes, given how much simpler it could be, I think it would be a STACK item
> > + that anybody could pick up. It works now, but for long-term maintenance, it
> > + would be nice to have a simplifed version.
> > +
> > + Cheers,
> > + -g
> > + ----------------------------------------------------------------------
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: svn-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: svn-help@subversion.tigris.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:51 2006