Re: [RFC] Target aware commit message processing

"Justin Erenkrantz" <justin_at_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_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org