It occurs to me that by switching to a URL-based commit drive (instead
of the current working-copy-path-based system), we throw a wrench into
several other things. For those not familiar with the new system I'm
trying to complete, it replaces a depth-first working copy
crawl/commit with a depth-first crawl/commit of the URLs associated
with the working copy things that have been modified.
Why the switch? Well, `switch` for one thing. ;-)
If I have, say, a checked-out working copy of the Subversion source
tree, and I want to work on a branch of libsvn_fs for a while, I would
do this:
svn cp http://svn.collab.net/repos/svn/trunk/subversion/libsvn_fs \
http://svn.collab.net/repos/svn/branches/cmpilato-branch
svn switch ./subversion/libsvn_fs \
http://svn.collab.net/repos/svn/branches/cmpilato-branch
This means that at libsvn_fs in my working copy, all of a sudden my
URL ancestry is no longer part of the same heirarchy as the rest of my
tree. This poses a problem for the current crawler if I have changes
in both my libsvn_fs (switched) dir and my libsvn_repos (not-switched)
dir. If I use `svn ci ./subversion/libsvn_fs ./subversion/libsvn_repos`
now, the common parent of "./subversion" will be chosen as the root of
my depth-first commit drive, and with it the URL of which it is a
reflection (http://svn.collab.net/repos/svn/trunk). But if that URL
is chosen as the TOP of my depth-first drive, it becomes rather
obvious that there is no way to even reach "http:// ... /svn/branches"!
Thus one of several reasons for the new system, which would, instead
of looking at paths (./subversion/libsvn_fs, ./subversion/libsvn_repos)
look instead the URLs for those things, choose the common parent of
http://svn.collab.net/repos/svn as the root of the commit, and commit
to "branches/cmpilato-branch" and "trunk/subversion/libsvn_repos".
So, enough about the background of the change. On to the ickiness.
------
Wait, one more piece of background. Before the commit ever begins,
and well after it ends, libsvn_client (and libsvn_client alone,
really) has the ability to map a committed thing's URL to a working
copy path and vice-versa.
------
The trace-commit editor is responsible for printing the path which is
being committed, and a verb to go with it:
Adding /home/cmpilato/tests/wc/boo
Sending /home/cmpilato/tests/wc/bah
...
Now, this particular editor could be switch to talk about repository
URLs, instead. So instead of seeing absolute disk paths, you'd see:
Adding http://servername.com/svn/cmpilato/boo
Sending http://servername.com/svn/cmpilato/bah
...
Alternatively, we could lose the trace-commit editor altogether and
simply have a custom callback vtable that would take WC paths, and
while those paths wouldn't necessarily be in depth-first order, they
would still be present.
Other ideas are welcome.
------
The commit-track editor is responsible for keeping track of what
things changed as part of a commit so that revisions can be bumped to
the new revision after the commit has succeeded. It lives inside the
RA layer, and is composed with the commit editor.
Now, I admit to not really understanding why this information has to
be kept inside of the RA layer. That is, why couldn't the working
copy just keep track of what it had committed, have the RA layer
simply answer the question "What is the new revision?", and then the
working copy bump its own revisions? But then again, I can't think of
a good way for the RA layer to answer that question, either.
At any rate, we now have this commit track editor which will know
nothing about the heirarchy of the working copy, and will instead
simply know that a bunch of URLs were changed.
I'm thinking that I'd love to knock that tracking editor out of the
picture since the new commit driver will know, prior to committing,
all of the committable items anyway -- why track them twice? If it
can only have the new-revision question answered, it can call
svn_wc_process_committed on each of the items, and there would be no
more need of the commit-track-hack editor.
------
I feel very strongly that a URL-based commit drive is Goodness, but
there are some definite deviations from the history thus far of
Subversion's commit processes, and that's presenting some challenges
to the idea. Ideas are soooooo welcome.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 19 15:59:31 2002