I think the problem is being somewhat misanalyzed in this thread.
The problem is this:
TSVN offers the user with a dialog box for the log message *before*
it knows all the paths involved in the commit. The user can start
writing the log message right away, while TSVN crawls the working
copy getting the status of everything. The interface allows the
user the check checkboxes for which files to include in the commit
-- including checking boxes to add unversioned files.
Since TSVN does not know all the paths being committed, let alone
what is being done with them ('M'odified or 'A'dded), it cannot
produce the right log message template at the beginning of this
crawl-and-query.
The misanalysis is to think that this problem is somehow a result of
network turnarounds or server-side hooks.
The real issue is that TSVN's current interface cannot work well with
*any* system that offers more than just one-static-template-pre-repos.
If the log message template is dependent in any way on the paths, then
TSVN cannot be sure it has got the right log message template until
after it knows all the paths being committed.
Notice the "dependent in any way" there. Even with no round-trip to
the server, there is still a problem. Suppose the template-production
system were done entirely using client-side properties, even iprops:
TSVN would *still* have to know what paths are being committed, in
order to produce the correct template or concatenation of templates.
By the way, I am totally in favor of designing log message templates
so they work well with TortoiseSVN and other GUI clients. That's not
controversial to me at all. The GUIs are important consumers of the
Subversion APIs, and should be taken into account.
I'm also not saying TSVN's commit interface is bad. Actually I think
it's terrific, and I below I'll offer one proposal to solve these
problems with only a minor change to the interface. All I'm saying is
that TSVN's current interface presents a problem for any decent log
message template system. Any template system that would satisfy our
goals would inevitably cause today's TSVN problems, since TSVN doesn't
know the paths being committed at the time it needs the template.
So please, let's not blame the network, or the hook proposal. They
are irrelevant here :-). This is purely about TSVN and paths.
Now, how to solve it?
I'm going to give an answer in terms of the server-side hook design,
because that's still the design I know best (I've been reading through
the relevant threads today, and while other designs are promising,
they are not yet as concrete as the hook proposal). But I don't think
any of what I say below is actually dependent on the hook proposal.
A Solution:
===========
When the commit interface comes up, TSVN queries the repository for a
log message template, sending an empty path list. The user writes the
log message, and also chooses the paths in the commit, adds some
unversioned files, whatever.
Now, it's time for TSVN to do the *real* commit. It knows all the
paths now. It again queries the srever for a log message template,
this time sending the complete path-change list. It compares the
resulting template with the one it fetched earlier (which it saved),
and if they are the same, then it continues with the commit and the
user never even knows about the second query.
If they are different, then TSVN pops up a warning dialogue. The
dialogue can show the two templates, or a diff between the two, or the
user's current completed log message and the new template, or
whatever. That's an interface detail that I leave in Steve's capable
hands; the point is that there is a moment when TSVN can detect
path-dependency in the template and ask the user what to do.
Of course, the other half of this solution is that smart repository
admins will set things up so that templates are not path-dependent
(and of course, Subversion would ship with a hook script that makes
this easy).
In fact, perhaps in the first template fetch, TSVN could send just one
path -- something it can quickly and easily get a handle on, like, the
URL to the root of the commit -- so that it's still possible to
project-specific templates transparently, without the warning dialogue
ever appearing.
I hope this explains why I think TSVN will be able to deal smoothly
with any template-production API we come up with.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 26 00:05:34 2005