[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: changelist feature -- keep it? tweak it? scrap it?

From: John Szakmeister <john_at_szakmeister.net>
Date: 2007-01-17 10:27:36 CET

----- Ben Collins-Sussman <sussman@red-bean.com> wrote:
[snip]
>
> * You say it "solves only the very most minor of use-cases that
> surround the scenario of working on multiple changesets in a
> single working copy at the same time." What are the major
> use-cases we're ignoring? I have the opposite impression, fwiw;
> in my experience, the current lightweight implementation solves
> 90% of the use-cases. (1) Looking at your list of patches, (2)
> Naming or destroying your patches, (3) Committing exactly one
> patch, and not another.
>
> (I don't consider overlapping changelists to be a common problem,
> and when it does happen, it almost always means that the patches
> *should* be developed in serial, not in parallel. So I don't
> think it's worthwhile to try to design a system that allows
> overlapping changelists to co-exist... to me, that's the 'minor'
> use-case.)

To be honest, overlapping (read: changes in the same file) are the ones that myself and my co-workers run into most often. The reason why is because as we're coding a feature or fixing a bug, we inevitably run across another (unrelated) bug that's in the code being modified, or just happened to see a problem in another piece of code that was nearby. I almost always resort to diff and patch, and whittle out parts of the patch that are unrelated.

That's not to say that I've never had non-overlapping changes, just that I run into the overlapping situation much more often than the non-overlapping situation. It probably has to do with the fact that code for our projects tend to run <20,000 lines, and the test suites generally take only a minute to run, so we don't have a need for doing multiple changesets at once. And when we do, it suffices to check out another WC and do it there.

-John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 17 10:27:53 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.