| -*-text-*- |
| |
| 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. |
| |
| (See http://subversion.tigris.org/project_tasks.html if you're looking |
| for a task to take on.) |
| |
| ------------------------------------------------------------------------ |
| |
| 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 |
| ---------------------------------------------------------------------- |