My understanding is that Dan Berlin and Dan Rall have been using the
feature, and in fact were the ones screaming for it when I first
proposed the idea. I also thought that Justin was using it. Anyone
else?
Stefan: it sounds like you've just made an argument against all
distributed version control systems. "Oh no! People will hold on to
private changes for too long!" :-) Consider this: a changelist
sitting in an svn working copy has no history to it. If thousands of
fans are busy switching to distributed version control systems and
creating multiple private copies of repositories, I don't think the
ability to manage shallow patches in a working copy is a real threat
to 'best practices'.
Similarly, I find it odd that CMike saying that he feels guilty about
working on two changes at once. It's completely normal to have
multiple patches in progress, especially on totally different parts of
the tree. It's just another form of multi-tasking -- like running
multiple applications on your computer. There's nothing morally wrong
or sloppy about it. And it's a really, really common scenario.
As DannyB said, it's usually about efficiency. Archiving and
unarchiving a patch with diff/patch isn't always convenient, and it's
also not convenient to just create a new working copy everytime a new
task comes up.
The implementation is pretty dead-simple and entirely client-side. I
think calling it 'large baggage to maintain' is a bit of a hyperbole.
:-)
- there is a single optional field in the entries file:
"changelist='foo'", settable by the 'svn changelist' subcommand.
- 'svn status' notices the uses the field to display file groupings
- 'svn commit' and 'svn revert' take optional '--changelist'
options, which uses the field as a filter.
I've been meaning to make other subcommands aware of the new field as
well, such as 'svn up', 'svn diff', 'svn log', but they haven't been
really high priority. I could certainly finish those if people wanted
me to.
All in all, I guess I'm saying that this is a pretty simple,
lightweight feature that's not hard to maintain, and it solves a
fairly common (and simple) itch.
Mike, if you have real criticisms, I'd be happy to discuss them in
detail. I need more elaboration from you, though.
* 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.)
* You say that you worry that the current implementation will make
it hard to implement hunk-level management. Can you explain why?
(Also, is this even a priority? I've never heard of users asking
for that, or heard it discussed on any svn roadmap.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 16 22:00:49 2007