"Sergey A. Lipnevich" <sergeyli@pisem.net> writes:
> Consider a documentation directory with 150 xml files all named
> similarly: chaper{001-150}.xml. If you've made changes in twenty five
> of them to replace "hyper" with "super", and in another three to
> describe a new feature, you'll have to first lookup what has changed
> (step 1), and then commit separately (steps 2-3). Having such a
> feature removes step 1: bring up the commit editor, sort out
> unnecessary files, commit.
See, this is the part of your argument that doesn't make sense. How
does this coder "sort out the unnecessary files"? By "looking up what
has changed" in those files. Don't you see, he *is* doing step 1 in
both scenarios, just at different times. The only way he can truly
skip step 1 is if he already knows which paths were part of which
group of changes, in which case this reverts to what I stated as the
only benefit of this system (see below, or my previous message).
> Another scenario is when both changes are scattered among several
> directories: "hyper" is changed for "super" in dir1/foo and
> dir2/bar, a new feature implemented in dir1/extrafoo and
> dir2/minibar. Instead of typing, one would pick the suitable lines
> and plunge ahead.
Right. Which is *exactly* the one benefit I mentioned:
"The only real benefit is that we've saved the guy from having to
type in a bunch of paths at the command-line."
> As I said, please do not overestimate coder discipline in other
> projects.
And likewise, please do not understate the steps in your scenarios so
that they suit your particular argument.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 14 17:45:18 2003