On Mon, 2008-09-22 at 22:03 +1000, Clint Lawrence wrote:
> Updated patches are attached. The change is split into two patches -
> libsvn_client.txt should be applied first, then client.txt.
>
> I've expanded my original patch a little and now externals and ignored
> items are handled correctly. The only major task that still needs to be
> completed is disabling the search for unversioned items when it's not
> required.
I am concerned about adding a chunk of code into the commit logic that
isn't closely aligned to the commit logic's task. In particular, I am
concerned about adding it into the library.
In the existing commit message template, to generate the list of items
to be committed, we know that the commit logic is generating that list
anyway. If we wanted the high-level client to generate that list
separately by using functions like "status", it would be duplicating
code and it might not be easy to ensure it was exactly right. Therefore
it makes sense for the commit logic to pass its list back to the
high-level client code.
When we want to display unversioned items in the message, I'm not sure
any of this argument applies. Is there a single definition of
"unversioned items" from the commit logic's point of view? I don't think
so. It is a concept of the user-interface presentation logic of "svn
status" and the preferences that control it (global-ignores, etc.).
Wouldn't it make sense for us to add this feature in the user interface
(client) code where it logically belongs? Is there a benefit to
embedding it in the commit logic in the library? (There's probably at
least a small speed advantage, but a large one?)
Taking a step back, isn't the output of "svn status" what we want to
see? I'm not clear why we would want a special subset of it. Let me give
some examples of what I mean:
* Do we want to ignore items in the global-ignores and the local
svn:ignore list? Undoubtedly. Then we perhaps should support a
"--no-ignores" switch like "svn status" does. I can easily say, "No we
shouldn't - that's going too far," but where is the rationale behind
that decision?
* Where should we look for unversioned items? The present patch, from
my quick glance, looks in each directory scanned for committables, and
also looks at the immediate siblings of each specified target. That's
fine for one user, but the next user wants to also see "cousins" like
"www/jpegs/unversioned.jpg" when committing "www/gifs/new.gif" as a
named target.
* If we look for unversioned items because the user might have
forgotten to add them, why do we not also look for the opposite: items
that are "missing" because the user deleted or moved them without
telling Subversion?
When I write a log message, I have a little utility with which I insert
a skeleton log message and a diff into my log message text [1], and then
I edit this and finally delete the diff lines before saving it. If I
wanted to see what files I'd forgotten, I would simply insert the output
of "svn status ." or "svn status COMMIT_TARGETS" into my text. Now, I
know that many popular editors don't make it easy to do that, but it
would feel right for us to provide some assistance for doing that in
Subversion's external log message editor program hook rather than
building in more special code.
- Julian
[1] The attached shell script "svnlogmsg".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
- application/x-shellscript attachment: svnlogmsg
Received on 2008-09-22 23:03:52 CEST