--On Monday, May 19, 2003 10:29 AM -0500 Ben Collins-Sussman
<sussman@collab.net> wrote:
> 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.
Yes, I do. This can be a problem in projects where prior review is needed
before a commit can occur (such as httpd). Or, you may have sent off a patch
for review by the rest of the developers (even if it is mandatory). You want
to keep the change applied in your tree while the review is pending so that
you can ensure that the change keeps building if other people change the API
or a conflict occurs.
Or, you are currently working on task1, urgent task2 comes in (and is
orthogonal), you can accomplish task2, diff/commit it, then go back to task1.
And, task2 may touch files in the same directory as task1, but not the same
files.
> So when I need to switch tasks mid-stream, I'll run
>
> $ svn diff > task1.patch
> $ svn revert . -R
> $ patch -p0 < task2.patch
>
> And as a result, I almost never run 'svn diff' on a list of
> targets... I either want to look at changes to a single file, or look
> at the whole set of changes within '.'
The problem with this scenario is that if something happens to task1.patch
where a conflict occurs, you will not detect it until it is too late. (This
is besides assuming you have a pristine WC - see below.) Or, as you change
something else (while waiting for review), you find that task1 broke something
else. By keeping it applied while the patch is outstanding, you know when
something has gone wrong. For example, I could have a patch to fix a problem
and asked for review. Unknowingly, another developer could apply another fix
to the same problem. Without it in my tree, it's hard to know that a conflict
occurred. (Yes, I do read the diff logs for my projects, but I'm not
perfect...)
Furthermore, when I run 'svn diff', I know that there are certain files in a
directory that aren't significant to the current task. I also know what files
I've modified for this task - therefore, I want explicit arguments to 'svn
diff' that can be performed cleanly.
The list of files that I pass to 'svn diff' may be the same as 'svn ci' (which
I why I said the interface is parallel - cmpilato doesn't agree with that
though). For example, in httpd, we've had a number of people run 'cvs commit'
that inadvertently commit other changes that they are working on and didn't
intend to commit. This is why 'svn/cvs commit' should always have explicit
paths sent to it rather than relying upon recursive by default. But, if you
can't pass that same list of arguments to 'svn diff', then I think something
is inherently broken.
The other reason I have multiple changesets in my tree is that I have local
modifications that are not intended to be committed. For example, I have a
number of local changes to Subversion (such as APR libtool support, a number
of autoconf workarounds, svn:permissions, svn switch --rewrite, mod_dav
changes, etc.). I can't run 'svn diff .' in my Subversion working copy and
get a clean output. And, I want all of them applied because I rely upon
having them in my own builds. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 19 17:53:51 2003