> Yeah, I'm failing to understand why people need 'svn diff' to default
> to the iterative case. Justin and Colin have said that the iterative
> use-case is a part of their "basic svn work-cycle", and Justin said he
> "often has multiple changesets" in his working copy.
For what it's worth, here is my experience regarding this issue,
as the maintainer of a CVS front-end:
PCL-CVS offers a display of all the modified files and ways to mark them
and operate on them (in Emacs). Some operations operate on the marked
files by default while others default to the current file only.
`diff' is one of the few operations that default "the current file only",
meaning that `cvs diff' will only be called with a single argument.
But note that this is only the "default" behavior. This default can be
changed (because people asked for it) and it can also be overridden
on a case by case basis (because I've needed it and other people have
also asked for it).
So, there is clearly a need for CVS users to call `cvs diff' on more than
a single file (or dir). But admittedly, it's not the most common use.
I don't see any particular reason for this situation to be substantially
different in Subversion, although cheap/lightweight/quick branches might
reduce the need for "iterated" diffs.
> This is not a dig against anybody's work habits... but do you really
> maintain mulitple changesets in a working-copy? How do you deal with
> that? I've been there, and it's always such a mess. When I encounter
> a bug, I never know if it's because of one changeset or another --
> there are too many changed variables to isolate the problem.
I have probably a couple hundred changesets in my working workarea for
the Emacs project. Yes, it's a mess, although a good part of those
changes a limited to a single file.
But how do you suggest I do it knowing that the time between "coding"
and "installing" can sometimes be counted in years ?
And having a hundred different workareas would not only kill
the 300MB left on my 4GB drive but it would also be a major maintenance
nightmare and wouldn't solve the problem of "testing" all those
changesets ?
Maybe my work habits aren't the best, but given the fact that it takes
a lot of work and time (additionally to coding) to get some changes
accepted into the repository, I think that any work habit will be messy,
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 19 18:29:59 2003