Google Git Google Git
Sign in
apache/subversion/refs/heads/issue-662-dev/./notes/STACK
blob: 694d07016993323ef864869008258513b80f63cb [file]
-*-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
----------------------------------------------------------------------