You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Troy Curtis Jr <tr...@gmail.com> on 2008/04/23 02:10:26 UTC
[RFC] Target aware commit message processing
I have been thinking about implementing commit message parsing such
that one can delete unwanted targets out of the commit message listing
to remove them from the commit (like svk). I have implemented a perl
wrapper script that does this but it has a few issues. I might be
able to work those issues out (though it isn't really worth it), but I
definitly would rather have a built-in option. The people in my group
have found it extremely useful in our day-to-day operations over the
past year so I feel it is worth the effort to implement for real.
My question: Who else thinks this would be useful? Has this been
proposed before, but implementation failed for one reason or another?
Perhaps most important, are there any committers who would have a
problem committing this feature?
I haven't seriously looked at the code to determine how much work it
will take, I wanted to gauge interest before I attempted it.
Troy
--
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Target aware commit message processing
Posted by Peter Wemm <pe...@wemm.org>.
On Wed, Apr 23, 2008 at 4:48 PM, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> On Wed, Apr 23, 2008 at 4:41 PM, Karl Fogel <kf...@red-bean.com> wrote:
> > "Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> > > If we do this (and it'd be cool, I think), I'd almost wonder if we
> > > should prompt the user to confirm "yes" or "no" that SVN processed the
> > > changed files correctly. This seems like a case where belt and
> > > suspenders are good. -- justin
> >
> > No, users will just habituate to typing "yes", and stop checking. (It's
> > possible to have yes/no prompts that users don't habituate to, but only
> > when those prompts appear in exceptional cases -- if they appear for
> > common cases, then they will inevitably be habituated to.)
>
> Well, I'd only prompt when the stuff below the marker changes...so I
> don't think the prompting would be *that* common. -- justin
I use this feature frequently in perforce. IMHO, There's no need to
prompt, because there's no destructive outcomes possible. The worst
case scenario is that you delete more than you should have, and have
to run another svn commit to get the changes committed. At the end of
the day, the result is the same.
I feel that 'Are you sure?' prompts should be reserved for
non-intuitive procedures, changes that have grave or destructive
consequences, or those that are particularly hard to undo. Don't
teach people to get used to the prompts.
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Target aware commit message processing
Posted by Daniel Shahaf <d....@daniel.shahaf.co.il>.
Justin Erenkrantz wrote on Wed, 23 Apr 2008 at 17:23 -0700:
> However, there are quite common scenarios where we may not be able to
> parse the lines properly. What happens when the log message doesn't
> have the special log lines? What do you do? Do you assume that you
> use the original set or that the user intended to commit nothing?
If the '--This line, and those below, will be ignored--' line is not
present, the former (committing all original targets) seems logical to me.
(I always delete this line and everything below it before committing,
because otherwise there is an annoying trailing EOL in the log message.)
> I can actually see both cases as reasonable interpretations - think of
> the '-F' case but also think of a user who wants to abort a commit
> after starting it and has already saved the log message.
I assumed the magic parsing would be not done to messages given by -F or
-m. In those cases, the special lines are not present in the first place,
so I do not see why they should be parsed. (We are not expecting people
to add the special lines manually, right?)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Target aware commit message processing
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Apr 23, 2008 at 10:20:58PM -0500, Troy Curtis Jr wrote:
> Also there is the case of moves. They are modeled as a copy-with-history and
> delete. With this feature you could potentially delete the 'deletion' part of
> the operation leaving only the copy, which is a significantly different
> operation. And after the commit is done, you are still left with a scheduled
> deletion. Maybe this is fine, after all you can already do it manually by
> specifying the copied file during a commit. But it is a little different.
> You are no longer just 'omitting' a change. Really the change is a
> 'move' which
> you turned into a 'copy', (possibly) followed by a 'delete' somewhere down the
> road.
Ouch, that rename thing *again*.
For now, you could look at the copy source (copies have 'copied-from'
pointers in the working copy), and check if the copy source
was deleted. Then add special markers to both files, like this:
A+ new (probably moved here from 'old')
D old (probably moved to 'new')
(A+ is 'add-with-history')
Note the word 'probably'. You can't be certain, because
the user might have deleted 'old', replaced it with something
else entirely, and then renamed the new thing.
wc-ng will hopefully make this easier to deal with.
--
Stefan Sperling <st...@elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No
Re: [RFC] Target aware commit message processing
Posted by Troy Curtis Jr <tr...@gmail.com>.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> If we do this (and it'd be cool, I think), I'd almost wonder if we
> should prompt the user to confirm "yes" or "no" that SVN processed the
> changed files correctly. This seems like a case where belt and
> suspenders are good. -- justin
>
"Greg Hudson" writes:
> I always liked this feature concept and was disappointed because it was
> shot down. It's kind of like a poor man's changelists, only without the
> massive UI footprint.
>
"Peter Wemm" writes:
> I use this feature frequently in perforce. IMHO, There's no need to
> prompt, because there's no destructive outcomes possible. The worst
> case scenario is that you delete more than you should have, and have
> to run another svn commit to get the changes committed. At the end of
> the day, the result is the same.
Awesome, it looks like a feature other people would appreciate so I'd like to
proceed. Maybe it will be patch #2 by me to Subversion!
Ya'll have already started discussing some of the interface issues, but I'll
begin my "official" collection of discussion on it now. A couple of things:
- I really like Stefan's idea of providing some feed back to the user during
the commit, i.e. uses his example:
Omitting a
Adding b
Transmitting file data.
Commited revision 1.
I think 'omitting' is a pretty good term and can be applied to all the cases
(scheduled to add, scheduled to delete, modified...). I'm not sure the banner
that Stefan suggested is necessary:
------------------------------------------------------
Some items were removed from the commit message listing,
omitting them.
------------------------------------------------------
Thoughts?
- I definitely would not like to prompt for confirmation. I'm glad to
have Karl
on my side here because I would not care to implement that! Karl has done a
great job explaining why it may not be that useful long-term and I second all
that he said.
- As I am currently thinking of it, the target omission logic would be
triggered
if Subversion finds it's special log line separator (which will have to change
of course). Justin's use case of deleting files out of the 'ignore' section
is still valid...as long as he also deletes the separator line. In his case
if he forgets to, nothing gets committed to the repository and he can realize
what happened, without being left in any kind of bad state.
So the logic would go something like this:
+ Does the log message contain the "magic" separator line?
+ Yes, parse the target list following the line
+ If parsing encounters a problem (like the user added something)
fail with an error message
+ No, proceed with the given commit
This would be applied to both the interactively prompted commit message file
(through whatever EDITOR was specified) and for the '-F' option. The -F
option is likely going to be the result of a previously failed commit, so we
would certainly want to have this functionality there.
- Then there is the discussion of the target list. Currently the list is
explicitly condensed to give more of an 'overview' of the commit. However,
when you are able to delete items from a commit then maybe it is useful to see
all the options so that you can choose targets at whatever granularity you want.
So my understanding of the condensing logic is that it mainly applies to a few
cases:
- Recursive delete
- Recursive add
- Recursive copies
In these cases it only shows the top-level directory of the operation. This is
done for a VERY good reason. Yet it might be nice to optionally see
everything. So perhaps there could be on option like '--no-condense' that
gives the full listing, and there could even be a config option to make that
global.
I suspect that more often than not, when you delete, add, or copy a directory
you would want it to stay together. So maybe an option is not useful?
Also there is the case of moves. They are modeled as a copy-with-history and
delete. With this feature you could potentially delete the 'deletion' part of
the operation leaving only the copy, which is a significantly different
operation. And after the commit is done, you are still left with a scheduled
deletion. Maybe this is fine, after all you can already do it manually by
specifying the copied file during a commit. But it is a little different.
You are no longer just 'omitting' a change. Really the change is a
'move' which
you turned into a 'copy', (possibly) followed by a 'delete' somewhere down the
road.
Are there other cases that I am missing here?
Troy
--
Beware of spyware. If you can, use the Firefox browser. - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Target aware commit message processing
Posted by Karl Fogel <kf...@red-bean.com>.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> I think we're differing about how common this would be - given this is
> a feature that doesn't exist in the CLI, I'm betting most folks would
> be acclimated to passing the proper args at the command line.
We're not differing about how common it would be, we're just talking
about different things. The number of folks who would use the feature
is irrelevant here. What's relevant is that, for those who *do* use it,
they are likely to use it often, and therefore will habituate to the
prompt, making it pointless.
> Yes, over time, it may change...
...and as it changes, the prompt becomes less and less useful :-).
> However, there are quite common scenarios where we may not be able to
> parse the lines properly. What happens when the log message doesn't
> have the special log lines? What do you do? Do you assume that you
> use the original set or that the user intended to commit nothing? I
> can actually see both cases as reasonable interpretations - think of
> the '-F' case but also think of a user who wants to abort a commit
> after starting it and has already saved the log message.
I'm not sure I fully understand the scenarios you're describing; I think
the interface may need to be spec'd out more for the above to be
answerable.
> All I'm advocating is that before we go off and do something that the
> user may or may not have intended, we confirm that we're doing the
> 'right' thing. Adding an extra prompt to commit if isn't what we
> started with is being conservative rather than being aggressive and
> assuming that we'll parse their intentions correctly 100%. I simply
> have no faith that we'll get it right. GUIs have a direct path -
> doing the confirmation in Tortoise would be stupid - but for the CLI
> we'd have to intuit the user's intentions via way of parsing an
> intermediate file.
If Subversion is uncertain, it shouldn't even attempt the commit. And I
don't see why Subversion would have trouble being certain: we're
declaring a parseable format, right?
> No, because if we do a switch *now* in 1.6 where we've always said
> "this will be ignored" and suddenly we don't ignore it, we've given
> folks a loaded gun and would lead I feel to unpredictable behavior.
>
> For example, in my typical use case, I write my log message and delete
> the lines from the 'ignore' section after I've completed the log
> message for each file. I like this new feature, but our precedent
> makes silent acceptance and intuition of what the user intends when
> they muck with those lines a bit dangerous. -- justin
Yes, for people who work the way you do (I don't know how many that is),
for a temporary period while they get accustomed to the feature, the
prompt would actually serve a purpose. Thereafter, it would be only an
annoyance. I don't think we should design a permanent UI around a
temporary transition period, especially when the consequences of the
user making a mistake are not grave anyway.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Target aware commit message processing
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Apr 23, 2008 at 5:02 PM, Karl Fogel <kf...@red-bean.com> wrote:
> The point is, it's 100% common *when the user has edited the lines*.
I think we're differing about how common this would be - given this is
a feature that doesn't exist in the CLI, I'm betting most folks would
be acclimated to passing the proper args at the command line. Yes,
over time, it may change...
However, there are quite common scenarios where we may not be able to
parse the lines properly. What happens when the log message doesn't
have the special log lines? What do you do? Do you assume that you
use the original set or that the user intended to commit nothing? I
can actually see both cases as reasonable interpretations - think of
the '-F' case but also think of a user who wants to abort a commit
after starting it and has already saved the log message.
Plus, the current collapsing logic in the log template isn't
consistent nor perfect. I'm not sure if we'd be able to properly
support *adding* files (like p4 does, IIRC) because we're so focused
on producing the smallest and most compact subset possible in the
template.
All I'm advocating is that before we go off and do something that the
user may or may not have intended, we confirm that we're doing the
'right' thing. Adding an extra prompt to commit if isn't what we
started with is being conservative rather than being aggressive and
assuming that we'll parse their intentions correctly 100%. I simply
have no faith that we'll get it right. GUIs have a direct path -
doing the confirmation in Tortoise would be stupid - but for the CLI
we'd have to intuit the user's intentions via way of parsing an
intermediate file.
> The prompt being proposed here doesn't have that property. It's both
> part of the expected procedure, and *not* part of any unexpected (thus
> unwanted) procedure. Since it doesn't have the latter property, it does
> no good.
No, because if we do a switch *now* in 1.6 where we've always said
"this will be ignored" and suddenly we don't ignore it, we've given
folks a loaded gun and would lead I feel to unpredictable behavior.
For example, in my typical use case, I write my log message and delete
the lines from the 'ignore' section after I've completed the log
message for each file. I like this new feature, but our precedent
makes silent acceptance and intuition of what the user intends when
they muck with those lines a bit dangerous. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Target aware commit message processing
Posted by Karl Fogel <kf...@red-bean.com>.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> On Wed, Apr 23, 2008 at 4:41 PM, Karl Fogel <kf...@red-bean.com> wrote:
>> "Justin Erenkrantz" <ju...@erenkrantz.com> writes:
>> > If we do this (and it'd be cool, I think), I'd almost wonder if we
>> > should prompt the user to confirm "yes" or "no" that SVN processed the
>> > changed files correctly. This seems like a case where belt and
>> > suspenders are good. -- justin
>>
>> No, users will just habituate to typing "yes", and stop checking. (It's
>> possible to have yes/no prompts that users don't habituate to, but only
>> when those prompts appear in exceptional cases -- if they appear for
>> common cases, then they will inevitably be habituated to.)
>
> Well, I'd only prompt when the stuff below the marker changes...so I
> don't think the prompting would be *that* common. -- justin
The point is, it's 100% common *when the user has edited the lines*.
In other words, mentally, the procedure for selecting files via the log
message just becomes:
- edit the lines
- exit the editor
- answer "yes" to the prompt.
Since the last two steps are habituatable, they will be habituated to --
and therefore become just a semi-unconscious annoyance to those who use
the feature.
Prompts only do good in so far as they are not part of the expected
procedure.
For example, my mailreader protects me from sending messages early by
prompting "yes or no" when I hit send. But this is not to remind me to
check over my mail when I'm done -- if that were the purpose, it would
do no good, because tpying "yes" right after the 'send' command is an
unconscious reflex now.
Rather, the prompt is there to protect me from *accidentally* sending,
for example, by accidentally hitting C-c C-c in the course of editing
the message. Although the prompt is a fully habituated part of the
"send a mail now" procedure, it is *not* a part of the "writing a mail"
procedure. Thus, if I find myself suddenly answering a yes-or-no box
when I didn't expect to, I know something's wrong, and *by the time I
realize that* I'm already outside any expected procedure, so must stop
and think anyway.
The prompt being proposed here doesn't have that property. It's both
part of the expected procedure, and *not* part of any unexpected (thus
unwanted) procedure. Since it doesn't have the latter property, it does
no good.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Target aware commit message processing
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Apr 23, 2008 at 4:41 PM, Karl Fogel <kf...@red-bean.com> wrote:
> "Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> > If we do this (and it'd be cool, I think), I'd almost wonder if we
> > should prompt the user to confirm "yes" or "no" that SVN processed the
> > changed files correctly. This seems like a case where belt and
> > suspenders are good. -- justin
>
> No, users will just habituate to typing "yes", and stop checking. (It's
> possible to have yes/no prompts that users don't habituate to, but only
> when those prompts appear in exceptional cases -- if they appear for
> common cases, then they will inevitably be habituated to.)
Well, I'd only prompt when the stuff below the marker changes...so I
don't think the prompting would be *that* common. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Target aware commit message processing
Posted by Karl Fogel <kf...@red-bean.com>.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> If we do this (and it'd be cool, I think), I'd almost wonder if we
> should prompt the user to confirm "yes" or "no" that SVN processed the
> changed files correctly. This seems like a case where belt and
> suspenders are good. -- justin
No, users will just habituate to typing "yes", and stop checking. (It's
possible to have yes/no prompts that users don't habituate to, but only
when those prompts appear in exceptional cases -- if they appear for
common cases, then they will inevitably be habituated to.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Target aware commit message processing
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Apr 23, 2008 at 2:43 PM, Stefan Sperling <st...@elego.de> wrote:
> I think Subversion should definitly be informing the user
> about changes it's omitting. Something like:
>
> "svn-commit.tmp" 4L, 60C written
> ---------------------------------------------------------------------
> Some items were removed from the commit message listing,
> omitting them.
> ---------------------------------------------------------------------
> Omitting a
> Adding b
> Transmitting file data .
> Committed revision 1.
If we do this (and it'd be cool, I think), I'd almost wonder if we
should prompt the user to confirm "yes" or "no" that SVN processed the
changed files correctly. This seems like a case where belt and
suspenders are good. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Target aware commit message processing
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Apr 22, 2008 at 09:10:26PM -0500, Troy Curtis Jr wrote:
> I have been thinking about implementing commit message parsing such
> that one can delete unwanted targets out of the commit message listing
> to remove them from the commit (like svk).
I don't know how svk behaves (I've only used it briefly, and liked
it), but does this mean that if I had a commit message like:
blah blah blah
--This line, and those below, will be ignored--
D a
A b
and I deleted the 'D a' line, the commit would not delete 'a',
effectively ignoring this local modification? And the same would
work for 'A a' and 'M a' lines and such?
Is taking changes out of a commit the only goal here or is
there more to this feature?
> I have implemented a perl
> wrapper script that does this but it has a few issues. I might be
> able to work those issues out (though it isn't really worth it), but I
> definitly would rather have a built-in option.
Do you mean "command line option" or "optional functionality that
is enabled by default?" I mean, I'd rather have this work by default,
cause if I was to take a file out of a changeset while writing a
log message, it would be cumbersome having to exit the editor and
run 'svn ci' again with --parse-my-commit-message-please.
> My question: Who else thinks this would be useful?
It maps a bit of Subclipse's commit file selection dialog
into the CLI, so yeah, why not.
I think Subversion should definitly be informing the user
about changes it's omitting. Something like:
"svn-commit.tmp" 4L, 60C written
---------------------------------------------------------------------
Some items were removed from the commit message listing,
omitting them.
---------------------------------------------------------------------
Omitting a
Adding b
Transmitting file data .
Committed revision 1.
--
Stefan Sperling <st...@elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No
Re: [RFC] Target aware commit message processing
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On Tue, Apr 22, 2008 at 10:26 PM, C. Michael Pilato <cm...@collab.net> wrote:
>> Troy Curtis Jr wrote:
>>
>>> My question: Who else thinks this would be useful? Has this been
>>> proposed before, but implementation failed for one reason or another?
>>> Perhaps most important, are there any committers who would have a
>>> problem committing this feature?
>>>
>> There is clearly at least some utility for it (though less so for
>> command-line clients than for GUI tools). And yes, it *has* been proposed
>> before (long ago ... seems like it was 2003 or 2004), but was shot down. If
>> you dig around in the archives a bit, you might be able to find the related
>> threads.
>
> Was this just a "typo"? It seems to me this feature only applies to
> the CLI. What use would it be for GUI tools? I do not think any of
> us use this feature and can already do this in our GUI dialogs.
Not a typo, just not well-explained. I was referring to the feature as a
general concept, not a particular implementation.
GUIs I've used tend today to present all the committables with little
checkboxes to decide which of them you really want to commit. They do this
because often your view of the working copy is either limited to a single
directory (such as with TortoiseSVN) or scattered in a directory tree widget
where, say, shift-selecting multiple commit targets would be annoying. In
other words, in a GUI, you practically *have* to have this ability to, at
commit time, select a subset of the available committables.
That's not the case for command-line clients, where you can craft the
perfect list of committables prior to invoking 'svn commit'.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: [RFC] Target aware commit message processing
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Apr 22, 2008 at 10:26 PM, C. Michael Pilato <cm...@collab.net> wrote:
> Troy Curtis Jr wrote:
>
> > My question: Who else thinks this would be useful? Has this been
> > proposed before, but implementation failed for one reason or another?
> > Perhaps most important, are there any committers who would have a
> > problem committing this feature?
> >
>
> There is clearly at least some utility for it (though less so for
> command-line clients than for GUI tools). And yes, it *has* been proposed
> before (long ago ... seems like it was 2003 or 2004), but was shot down. If
> you dig around in the archives a bit, you might be able to find the related
> threads.
Was this just a "typo"? It seems to me this feature only applies to
the CLI. What use would it be for GUI tools? I do not think any of
us use this feature and can already do this in our GUI dialogs.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Target aware commit message processing
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2008-04-22 at 22:26 -0400, C. Michael Pilato wrote:
> Troy Curtis Jr wrote:
> > My question: Who else thinks this would be useful? Has this been
> > proposed before, but implementation failed for one reason or another?
> > Perhaps most important, are there any committers who would have a
> > problem committing this feature?
>
> There is clearly at least some utility for it (though less so for
> command-line clients than for GUI tools). And yes, it *has* been proposed
> before (long ago ... seems like it was 2003 or 2004), but was shot down. If
> you dig around in the archives a bit, you might be able to find the related
> threads.
I think you can even find a patch for it if you dig hard enough, though
it would be against an ancient version of the code base.
I always liked this feature concept and was disappointed because it was
shot down. It's kind of like a poor man's changelists, only without the
massive UI footprint.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Target aware commit message processing
Posted by "C. Michael Pilato" <cm...@collab.net>.
Troy Curtis Jr wrote:
> My question: Who else thinks this would be useful? Has this been
> proposed before, but implementation failed for one reason or another?
> Perhaps most important, are there any committers who would have a
> problem committing this feature?
There is clearly at least some utility for it (though less so for
command-line clients than for GUI tools). And yes, it *has* been proposed
before (long ago ... seems like it was 2003 or 2004), but was shot down. If
you dig around in the archives a bit, you might be able to find the related
threads.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand