On 8/19/07, Talden <talden@gmail.com> wrote:
> That is, "svn diff --changelist
> > foo" may not show all of the changes conceptually on changelist "foo";
> > instead, it shows those changes that are at or below the current
> > directory.
>
> Equally unintuitive but understandable given the WC model.
>
Luckily, we designed the API for changelists in such a way such that
they *could* live in a centralized database. After some list
discussion, we decided to do this so that a better libsvn_wc 2.0
really could return all paths in a CL, not just the ones below the
current working directory.
> > On the other hand, I think it's rather unexpected
> > that "svn ci foo.c" removes foo.c from any changelist it's on even
> > though changelists aren't being mentioned at all.
Yeah, that does seem weird to me. I think we should fix that, or file
it as a bug.
> If changelists are intended to hold paths rather than scheduled
> changes then I'd have expected items to stay on changelists and for
> changelists to be a feature of the working copy as a whole - allowing
> a path to be listed on multiple changelists
Er, um... you really don't want a path to be part of 2 changelists at
once. That would imply two overlapping patches, and 'svn ci
---changelist cl1' wouldn't know which 'hunks' of patches to commit.
This was a scenario we deliberately decided to avoid when we designed
this fetaure.
> and for changelists to be
> persistent after commits (unless a user specified option at
> commit-time cleared the paths from the specified list) would allow for
> a more natural usage if changelists really are lists of paths rather
> than scheduled changes.
We're deliberately modeling perforce here. That's why the default
behavior is for 'svn commit' to destroy changelists, rather than keep
them around. It's also consistent with the way our locking feature
works. ('svn commit' uses a lock to do the commit, then automatically
releases the lock by default.)
>
> I think a major review of many of these decisions (and unfortunately a
> shift in the meaning of some concepts for the user) will be necessary
> when/if the fundamental centralisation of working copy book-keeping is
> ever done.
Agreed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 19 14:46:42 2007