You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2007/01/16 19:29:14 UTC
changelist feature -- keep it? tweak it? scrap it?
I hate to bring this up at so late a date, but Stefan Küng's recent mail
reminded me of it.
At some point in the past, I was out in San Francisco for business and
chatting with a number of Subversion committers -- Karl, Garrett,
possibly Dan Rall, and maybe someone else... I can't recall. Anyway, as
we were walking north on Dolores, the topic of the changelist feature
came up, and my recollection was that we all pretty much agreed that, as
written, it didn't actually solve any interesting problem that didn't
already have a simple (albeit mildly annoying) workaround, and that the
feature and its maintenance were, by and large, unjustifiable baggage.
Now, opinions may have changed since then, so I don't want to come
across like a spokesman for whoever it was I was walking with at the
time. But if we release this feature in 1.5, it will be incredibly
difficult to unrelease it later. So I want to make sure that we have
actively decided that the feature is a good thing, and more importantly,
a good enough to thing to support.
My opinion is pretty easy to express: nice idea, but 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. And I'm
concerned about the possibility of the existing feature getting in the
way of what would *really* be useful, which is moving the granularity of
a changelist from per-file to per-diff-hunk or per-line.
If the community is cool with the feature as it stands, fantastic.
Obviously, this isn't MikeVersion. But I just don't get the impression
that the votes for it thus far have been anything other than +/-0. Is
anyone using this feature?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Daniel Berlin <db...@dberlin.org>.
On 1/16/07, C. Michael Pilato <cm...@collab.net> wrote:
> Daniel Berlin wrote:
> > On 1/16/07, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> >> On 1/16/07, C. Michael Pilato <cm...@collab.net> wrote:
> >> > written, it didn't actually solve any interesting problem that didn't
> >> > already have a simple (albeit mildly annoying) workaround, and that the
> >> > feature and its maintenance were, by and large, unjustifiable baggage.
> >>
> >> What's the simple workaround? It's a very helpful feature if you have
> >> multiple patches in your tree. Or, am I misunderstanding something?
> >> -- justin
> >
> > Yeah, i don't get the "mildly annoying" workaround either.
>
> svn diff + patch, give or take any property edits?
This is a great way to end up accidentally submitting/committing
patches that contain things they shouldn't. It's hard to end up with
truly self-contained patches in GCC, and if i don't tag what i'm
working on with the changelist i'm working on it for, you can forget
why it's there.
Which isn't just bad when it happens, it makes you look bad, too.
:)
>
> > I use it to work on multiple changes in my gcc trees and manage them
> > all the time using this.
>
> Well, I'm glad to hear that somebody is using it. That's the kind of
> input I was hoping to get from this query.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by John Peacock <jp...@rowman.com>.
C. Michael Pilato wrote:
> svn diff + patch, give or take any property edits? I constantly have
> multiple patches-in-progress in my working copies, too, but a) manage
> them just fine with 'svn diff' and patch, and b) always feel kinda
> naughty, like I'm violating a best practice, for not keeping my tree
> limited to a single changeset at a time.
FWIW, I don't see anything that the changelist feature gains you when
SVK is so much more natural to use:
$ cpan install SVK
$ svk mirror http://remote/repo/project //mirrors/project
$ svk sync //mirrors/project
$ svk cp -p //mirrors/project/trunk //local/project/trunk
$ svk co //local/project/trunk project
$ yada yada yada
You can keep multiple local branches and use a single working copy, so
you are only paying the additional storage cost twice (modulo how much
of the remote repository you want to mirror, which can be all or just
part of the original history).
YMMV
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Daniel Berlin wrote:
> On 1/16/07, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>> On 1/16/07, C. Michael Pilato <cm...@collab.net> wrote:
>> > written, it didn't actually solve any interesting problem that didn't
>> > already have a simple (albeit mildly annoying) workaround, and that the
>> > feature and its maintenance were, by and large, unjustifiable baggage.
>>
>> What's the simple workaround? It's a very helpful feature if you have
>> multiple patches in your tree. Or, am I misunderstanding something?
>> -- justin
>
> Yeah, i don't get the "mildly annoying" workaround either.
svn diff + patch, give or take any property edits? I constantly have
multiple patches-in-progress in my working copies, too, but a) manage
them just fine with 'svn diff' and patch, and b) always feel kinda
naughty, like I'm violating a best practice, for not keeping my tree
limited to a single changeset at a time.
> I use it to work on multiple changes in my gcc trees and manage them
> all the time using this.
Well, I'm glad to hear that somebody is using it. That's the kind of
input I was hoping to get from this query.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Daniel Berlin <db...@dberlin.org>.
On 1/16/07, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On 1/16/07, C. Michael Pilato <cm...@collab.net> wrote:
> > written, it didn't actually solve any interesting problem that didn't
> > already have a simple (albeit mildly annoying) workaround, and that the
> > feature and its maintenance were, by and large, unjustifiable baggage.
>
> What's the simple workaround? It's a very helpful feature if you have
> multiple patches in your tree. Or, am I misunderstanding something?
> -- justin
Yeah, i don't get the "mildly annoying" workaround either.
I use it to work on multiple changes in my gcc trees and manage them
all the time using this.
The only workaround i can see would be have more checked out trees, at
another 2 gig a pop.
I've already got 6.
Each probably has 3-4 changelists in it (they get moved to a temporary
tree when they are ready in order to do truly clean testing).
That's not only a disk space increase, it's also a factor of 3 work
increase in keeping these trees up-to-date and doing quick testing on
it. Now i've got to run the testsuite 18-24 times to get any coverage
at all of every patch, instead of 6 times.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 1/16/07, C. Michael Pilato <cm...@collab.net> wrote:
> written, it didn't actually solve any interesting problem that didn't
> already have a simple (albeit mildly annoying) workaround, and that the
> feature and its maintenance were, by and large, unjustifiable baggage.
What's the simple workaround? It's a very helpful feature if you have
multiple patches in your tree. Or, am I misunderstanding something?
-- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Giovanni Bajo <ra...@develer.com>.
On 16/01/2007 21.21, Stefan Küng wrote:
> But maybe that implementation could be implemented in reverse?
> Right now, you can commit all files belonging to a specific changeset.
> How about having a 'blockset' instead of a changeset? The blockset would
> always get filtered out from a commit (something like svn:ignored on
> versioned files).
That'd be really *great*. It happens pretty often to have that little local
hack which you don't want to properly fix right now, you just want to have it
in your working copy to get your actual work done. If you could block that
from accidental commit, it'd save a lot of time and mistakes :)
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Stefan Küng <to...@gmail.com>.
C. Michael Pilato wrote:
> came up, and my recollection was that we all pretty much agreed that, as
> written, it didn't actually solve any interesting problem that didn't
> already have a simple (albeit mildly annoying) workaround, and that the
> feature and its maintenance were, by and large, unjustifiable baggage.
I haven't looked at the implementation details in the source, so I don't
know how big that baggage really is.
But I agree that the feature doesn't solve big problems. In fact, I
think it will mostly lead to bad working practices:
IMHO it is better to commit often and not hold of a commit too long. And
that's exactly what will happen with this feature. People will start
working on a change, put those files into a changelist and postpone
committing it a long time. What they won't notice is that some other
change they made might also have changed one or more files they put into
such a changelist -> bad commit which breaks the build.
But maybe that implementation could be implemented in reverse?
Right now, you can commit all files belonging to a specific changeset.
How about having a 'blockset' instead of a changeset? The blockset would
always get filtered out from a commit (something like svn:ignored on
versioned files).
> My opinion is pretty easy to express: nice idea, but 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. And I'm
> concerned about the possibility of the existing feature getting in the
> way of what would *really* be useful, which is moving the granularity of
> a changelist from per-file to per-diff-hunk or per-line.
That would of course be a big and great feature. But not easy to implement.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Daniel Rall wrote:
...
> The --targets option handles roughly half the features provided by
> today's changelist implementation. How --targets is intended to be
> used isn't perfectly clear, though:
>
> $ svn help ci | grep 'targets arg '
> --targets arg : pass contents of file ARG as additional args
>
> It would be nice if either --targets or changelist was implemented
> consistently across commands, and if there was a more clear
> distinction on when to use what, and what --targets was really
> intended to do (since it sounds like you can use it to pass arbitary
> arguments).
...
There was some discussion about the --targets switch several months
back. See http://svn.haxx.se/dev/archive-2006-04/0831.shtml and
surrounding posts.
There was some discussion as to what the behavior of multiple --targets
switches should be, and how the --targets switch should interact with
other arguments. In the end, nothing really happened with it.
-Hyrum
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Daniel Rall <dl...@collab.net>.
On Wed, 17 Jan 2007, Karl Fogel wrote:
> On 1/17/07, Jonathan Gilbert <o2...@sneakemail.com> wrote:
> >Why not change the current API, which does "set changelist for file X to
> >Y", into two functions: "add file X to changelist Y" and "remove file X
> >from changelist Y"? The current implementation would simply return an error
> >when trying to add a file that is already in one changelist to another one,
> >but it leaves the door open for changes to the way the data is actually
> >stored.
> >
> >Similarly, while certain operations naturally strobe all of the files
> >anyway as part of their normal processing and thus have virtually no
> >overhead in asking each file X if it is a part of changelist Y, it's
> >certainly true that some operations would like to be able to enumerate the
> >files specific to a changelist as quickly as possible. If a function is
> >added to the API to "list all files that are part of changelist Y", it can
> >be initially implemented as a recursive scan, the way it currently has to
> >be done anyway, but then applications that are built using it will
> >automatically experience a performance gain if/when the database structure
> >is reworked.
> >
> >By designing the API carefully, the back-end implementation details can be
> >completely masked, and the door kept open for changing the implementation
> >to better support the end goal feature set. Isn't that one of the main
> >goals of putting implementation into a library? :-) (the other one being
> >reusability)
>
> I think Jonathan's recommendation is the best course at this point. Let's
> rework the API as though we had an ideal database-ish interface for
> storing changelist information, and (for now) just implement that API
> in libsvn_wc in a somewhat non-optimal way. Unfortunately, when I
> say "Let's", I really mean "Someone else please" :-)... I'd like to
> concentrate
> on sparse directories for now. I will, however, watch the new API if
> someone does this, and make any comments up front instead of months
> later.
I favor this approach too. +1
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Karl Fogel wrote:
> On 1/18/07, Daniel Rall <dl...@collab.net> wrote:
>> Implicitly severable WCs have to go. Especially after implementing
>> Merge Tracking, I am convinced that we need centralized meta data
>> storage for the WC (in the spirit of Dave Anderson's "Another working
>> copy library" email). We can certainly provide an explicit
>> sub-command to break off portions of the WC, maintaining the feature
>> desired by Justin.
>
> +1 all over that, for both severability and portability.
Yeah, as one probably of the loudest proponents of severability, I'm
willing to resort to the likes of an 'svn sever' type explicit action if
(since) it means such apparently fantastic performance and
simplification gains.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Karl Fogel <kf...@red-bean.com>.
On 1/18/07, Daniel Rall <dl...@collab.net> wrote:
> Implicitly severable WCs have to go. Especially after implementing
> Merge Tracking, I am convinced that we need centralized meta data
> storage for the WC (in the spirit of Dave Anderson's "Another working
> copy library" email). We can certainly provide an explicit
> sub-command to break off portions of the WC, maintaining the feature
> desired by Justin.
+1 all over that, for both severability and portability.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Greg Stein <gs...@gmail.com>.
I have never severed a working copy. Ever. Not on CVS. Not on SVN.
Double +1 with a wrist-flick snap. Kill it in whatever manner desired.
On 1/18/07, Daniel Rall <dl...@collab.net> wrote:
> On Wed, 17 Jan 2007, Malcolm Rowe wrote:
>
> > On Wed, Jan 17, 2007 at 04:00:51PM -0600, Karl Fogel wrote:
> > > To Justin: my sense is that most people are ready to give up on
> > > severable & relocatable (with just 'mv') working copies now, the
> > > costs are starting to outweigh the benefits. But I agree, we don't
> > > need to open that can of worms right now.
> >
> > Implicitly severable, yes, but I think people want explicitly severable
> > working copies. Portable (or implicitly movable) working copies seem
> > more important (I use one almost every time I commit, for example).
>
> Implicitly severable WCs have to go. Especially after implementing
> Merge Tracking, I am convinced that we need centralized meta data
> storage for the WC (in the spirit of Dave Anderson's "Another working
> copy library" email). We can certainly provide an explicit
> sub-command to break off portions of the WC, maintaining the feature
> desired by Justin.
>
>
>
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Daniel Rall <dl...@collab.net>.
On Wed, 17 Jan 2007, Malcolm Rowe wrote:
> On Wed, Jan 17, 2007 at 04:00:51PM -0600, Karl Fogel wrote:
> > To Justin: my sense is that most people are ready to give up on
> > severable & relocatable (with just 'mv') working copies now, the
> > costs are starting to outweigh the benefits. But I agree, we don't
> > need to open that can of worms right now.
>
> Implicitly severable, yes, but I think people want explicitly severable
> working copies. Portable (or implicitly movable) working copies seem
> more important (I use one almost every time I commit, for example).
Implicitly severable WCs have to go. Especially after implementing
Merge Tracking, I am convinced that we need centralized meta data
storage for the WC (in the spirit of Dave Anderson's "Another working
copy library" email). We can certainly provide an explicit
sub-command to break off portions of the WC, maintaining the feature
desired by Justin.
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Wed, Jan 17, 2007 at 04:00:51PM -0600, Karl Fogel wrote:
> To Justin: my sense is that most people are ready to give up on
> severable & relocatable (with just 'mv') working copies now, the
> costs are starting to outweigh the benefits. But I agree, we don't
> need to open that can of worms right now.
>
Implicitly severable, yes, but I think people want explicitly severable
working copies. Portable (or implicitly movable) working copies seem
more important (I use one almost every time I commit, for example).
Regards,
Malcolm
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Nik Clayton <ni...@ngo.org.uk>.
Karl Fogel wrote:
> To Dan Berlin: Stellation (IIRC) implemented hunk-level changelists.
> It's not so blue-sky as all that. As I described, it's a client interface
> job for the most part: it could be implemented *today* over Subversion
> without changing a line of code and without using any of the new
> changelist APIs. Indeed, maybe Subclipse will take that tack eventually.
I think it's been mentioned before, but in case it got lost in the noise,
svk (2.0) also has the ability to prepare and manage hunk-level changelists
with the interactive commit/patch feature.
N
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Karl Fogel <kf...@red-bean.com>.
On 1/17/07, Jonathan Gilbert <o2...@sneakemail.com> wrote:
> Why not change the current API, which does "set changelist for file X to
> Y", into two functions: "add file X to changelist Y" and "remove file X
> from changelist Y"? The current implementation would simply return an error
> when trying to add a file that is already in one changelist to another one,
> but it leaves the door open for changes to the way the data is actually
> stored.
>
> Similarly, while certain operations naturally strobe all of the files
> anyway as part of their normal processing and thus have virtually no
> overhead in asking each file X if it is a part of changelist Y, it's
> certainly true that some operations would like to be able to enumerate the
> files specific to a changelist as quickly as possible. If a function is
> added to the API to "list all files that are part of changelist Y", it can
> be initially implemented as a recursive scan, the way it currently has to
> be done anyway, but then applications that are built using it will
> automatically experience a performance gain if/when the database structure
> is reworked.
>
> By designing the API carefully, the back-end implementation details can be
> completely masked, and the door kept open for changing the implementation
> to better support the end goal feature set. Isn't that one of the main
> goals of putting implementation into a library? :-) (the other one being
> reusability)
I think Jonathan's recommendation is the best course at this point. Let's
rework the API as though we had an ideal database-ish interface for
storing changelist information, and (for now) just implement that API
in libsvn_wc in a somewhat non-optimal way. Unfortunately, when I
say "Let's", I really mean "Someone else please" :-)... I'd like to concentrate
on sparse directories for now. I will, however, watch the new API if
someone does this, and make any comments up front instead of months
later.
Sorry that I didn't say something about this when you were writing the code,
Ben -- I was busy getting settled into a new city and new job and not able
to follow dev@ carefully then. I knew you were working on the feature, but
I didn't have time to look at the actual commits.
To Justin: my sense is that most people are ready to give up on
severable & relocatable (with just 'mv') working copies now, the
costs are starting to outweigh the benefits. But I agree, we don't
need to open that can of worms right now.
To Dan Berlin: Stellation (IIRC) implemented hunk-level changelists.
It's not so blue-sky as all that. As I described, it's a client interface
job for the most part: it could be implemented *today* over Subversion
without changing a line of code and without using any of the new
changelist APIs. Indeed, maybe Subclipse will take that tack eventually.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Jonathan Gilbert <o2...@sneakemail.com>.
At 09:15 PM 1/16/2007 -0600, Karl Fogel wrote:
>> To keep track of changelists, one needs to do some bookkeeping... just
>> associate a name with a list of files. You're advocating that every
>> single client app create some sort of private database to do this?
>> But wait... we already *have* a database of sorts... the entries file!
>> It's sitting right there, in front of every app. It's utterly
>> trivial to store a label in an svn_entry_t.
>>
>> So that's exactly the API I wrote: (1) an API to add/remove a
>> changelist label from a path (by adding/removing it from the
>> underlying svn_entry_t). (2) an API to search the working copy for
>> all paths matching a changelist. Basic database functionality,
>> nothing more.
>
>And really poor database functionality, from an indexing standpoint.
>Even though users almost always deal with changesets by name,
>SVN has to reach them backwards: to reconstruct changelist X,
>we ask every file if it's in X, instead of asking X what files are in it!
>In large working copies, this isn't great... :-)
Why not change the current API, which does "set changelist for file X to
Y", into two functions: "add file X to changelist Y" and "remove file X
from changelist Y"? The current implementation would simply return an error
when trying to add a file that is already in one changelist to another one,
but it leaves the door open for changes to the way the data is actually
stored.
Similarly, while certain operations naturally strobe all of the files
anyway as part of their normal processing and thus have virtually no
overhead in asking each file X if it is a part of changelist Y, it's
certainly true that some operations would like to be able to enumerate the
files specific to a changelist as quickly as possible. If a function is
added to the API to "list all files that are part of changelist Y", it can
be initially implemented as a recursive scan, the way it currently has to
be done anyway, but then applications that are built using it will
automatically experience a performance gain if/when the database structure
is reworked.
By designing the API carefully, the back-end implementation details can be
completely masked, and the door kept open for changing the implementation
to better support the end goal feature set. Isn't that one of the main
goals of putting implementation into a library? :-) (the other one being
reusability)
>The issue is not that other clients are hindered, nor is it that the
>current library *code* is too complex. The issue is about APIs:
>every time we add something, we're stuck with it, and my instinct
>is that down the road we're going to regret these interfaces --
>"regret" in the sense that, as clients figure out what they really
>want from changelists, the APIs we added now will turn out to
>be slightly off from what's needed. Sure, we can add whatever
>the clients need later, and just have some old cruft in our APIs
>that no one uses. Small prices, paid repeatedly, add up, that's all.
This is what I'm talking about above :-) The lesson isn't that we should
put off implementing anything until we know exactly how it needs to be
implemented, but rather that we simply need to spend a bit more time
thinking about the interface we give, so that we prevent UI authors from
taking shortcuts while keeping things flexible enough for them to be
improved upon later.
>(I think your point about the library changes being really tiny cuts
>both ways. If they're small, then the benefits of supplying them
>for all clients can't be that large either.)
As was mentioned in another rebuttal, it's not about the size of the
changes, but about where they're placed. Even though the functionality is
simple, virtually *every* client is going to want a piece of the action,
and if they all make their own databases, then they won't be talking to one
another. That Eclipse user is going to be pissed off when he discovers that
all the changelists he set up in the nice Eclipse GUI don't exist as far as
the command-line client is concerned :-)
>If we absolutely *must* provide library-level support, I wish we'd do it
>in the configuration area code instead of libsvn_wc, so that we could
>at least index changesets in a conceptually appropriate way, with both
>proper performance and proper semantics.
Moving the existing API to the configuration area code won't improve its
interface. Subversion currently has no centralized concept of working
copies on a system -- they exist on their own, like little islands in the
rest of the filesystem, no? Given this, does it not make sense that
changelists, since they are not managed by the server, would be WC-specific?
Perhaps I'm just misunderstanding and it would make perfect sense to put
WC-specific functionality into the configuration area code. I don't know
the Subversion code-base all that well...
Jonathan Gilbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Daniel Berlin <db...@dberlin.org>.
On 1/16/07, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Tue, Jan 16, 2007 at 09:15:55PM -0600, Karl Fogel wrote:
> > And really poor database functionality, from an indexing standpoint.
> > Even though users almost always deal with changesets by name,
> > SVN has to reach them backwards: to reconstruct changelist X,
> > we ask every file if it's in X, instead of asking X what files are in it!
> > In large working copies, this isn't great... :-)
>
> I don't think it's quite that bad - plus we have loads of other issues with
> large-scale working copies anyway. (Let's start with optional text bases
> if you want to start the laundry list of what's wrong with large WCs.)
>
> I am also very much against losing shareable/severable working copies. So,
> I'm largely against binding WC features inside of ~/.subversion etc. But,
> that's not on the table yet...or is it?
I'll leave this one alone, because i have very strong views in the
other direction, and it's not on the table yet, afaik.
> I honestly don't see the use case for overlapping changesets yet. Plus, I
> think hunk-level selection is so far a very green-field feature that hasn't
> been paid much attention yet. I think we're going to have *lots* of issues
> if we want to partially commit a file. How do we even know what chunk to
> give? Our streams are all binary - but that's often of little benefit to
> the user. The user would want to commit the changes on line 10, but not on
> line 20. How does that translate? (I don't think it can with svndiff1 on
> first glance.)
Well, you can translate it. There is nothing about a binary diff
algorithm or svndiff1 that prevents you from only adding some subset
of changes. In the case above, you simply don't include line 20's
changes (which are at byte whatever of the file to byte whatever else)
in the delta stream.
Effectively, you pre-translate the file to exclude those changes, then delta it.
You can do this on the fly while sending the file to be delta'd,
assuming you have a list of lines you want to exclude.
Though it does require a lot more memory accesses than it did before :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Jan 16, 2007 at 09:15:55PM -0600, Karl Fogel wrote:
> And really poor database functionality, from an indexing standpoint.
> Even though users almost always deal with changesets by name,
> SVN has to reach them backwards: to reconstruct changelist X,
> we ask every file if it's in X, instead of asking X what files are in it!
> In large working copies, this isn't great... :-)
I don't think it's quite that bad - plus we have loads of other issues with
large-scale working copies anyway. (Let's start with optional text bases
if you want to start the laundry list of what's wrong with large WCs.)
I am also very much against losing shareable/severable working copies. So,
I'm largely against binding WC features inside of ~/.subversion etc. But,
that's not on the table yet...or is it?
> (I think your point about the library changes being really tiny cuts
> both ways. If they're small, then the benefits of supplying them
> for all clients can't be that large either.)
My take is that if it's at the 'right' layer, it's often a lot simpler.
> Here's another concrete example of where I think the current libsvn_wc
> changes will fall down:
>
> The svn_wc_entry_t 'changelist' field is only meant to hold one changelist
> name. There's no way to compatibly store multiple changelist names
> in .svn/entries right now (so much for a general-purpose database). Yet
> overlapping changesets are surely in the future of this feature, especially
> when hunk-level selection gets implemented! And once people start doing
> stuff like that, even if we *could* keep all the information in
> .svn/entries, we
> probably wouldn't want to.
I honestly don't see the use case for overlapping changesets yet. Plus, I
think hunk-level selection is so far a very green-field feature that hasn't
been paid much attention yet. I think we're going to have *lots* of issues
if we want to partially commit a file. How do we even know what chunk to
give? Our streams are all binary - but that's often of little benefit to
the user. The user would want to commit the changes on line 10, but not on
line 20. How does that translate? (I don't think it can with svndiff1 on
first glance.)
> So, no, I don't think we're creating a good foundation for the future. If
> we absolutely *must* provide library-level support, I wish we'd do it
> in the configuration area code instead of libsvn_wc, so that we could
> at least index changesets in a conceptually appropriate way, with both
> proper performance and proper semantics.
I think we evolve it at a later time if and when someone wants to support
overlapping change sets. Until then, I'm happy for the feature to stay
as-is. If and when patches emerge, then we deal with it. But, trying to
revert working (and useful) code because it might conflict with something
later (that hasn't even been designed or thought through on-list) seems
like we're putting the cart before the horse. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Daniel Berlin <db...@dberlin.org>.
>
> > I think you are vastly overestimating the complexity of the existing
> > code. It's nothing more than an extra field in svn_entry_t, and
> > teaching some svn_client_* APIs to filter on that field. The "hard"
> > stuff -- like UI -- already rests squarely at the application level,
> > exactly where you think it should be.
> >
> > (Does the current commandline UI stink? Maybe? Then let's fix the
> > commandline client. Let's encourage TortoiseSVN to do something cool
> > and GUI-like. AFAICT, no client has been hindered here by the
> > existing code, only helped.)
>
> The issue is not that other clients are hindered, nor is it that the
> current library *code* is too complex. The issue is about APIs:
> every time we add something, we're stuck with it, and my instinct
> is that down the road we're going to regret these interfaces --
This is always true. you always regret doing something 5 or 10 years later.
That is why you only guarantee compatibility for as long as you can
stand to maintain the API.
:)
> "regret" in the sense that, as clients figure out what they really
> want from changelists, the APIs we added now will turn out to
> be slightly off from what's needed. Sure, we can add whatever
> the clients need later, and just have some old cruft in our APIs
> that no one uses. Small prices, paid repeatedly, add up, that's all.
This is our choice though. We control the price we pay, and how long we pay it.
>
> (I think your point about the library changes being really tiny cuts
> both ways. If they're small, then the benefits of supplying them
> for all clients can't be that large either.)
>
> Here's another concrete example of where I think the current libsvn_wc
> changes will fall down:
>
> The svn_wc_entry_t 'changelist' field is only meant to hold one changelist
> name. There's no way to compatibly store multiple changelist names
> in .svn/entries right now (so much for a general-purpose database). Yet
> overlapping changesets are surely in the future of this feature, especially
> when hunk-level selection gets implemented! And once people start doing
> stuff like that, even if we *could* keep all the information in .svn/entries, we
> probably wouldn't want to.
So you fix the small design and implementation issues. you don't rip
the whole thing out!
Do you believe this is a feature where there really is some
"laboratory of clients" that are going to try tings differently?
I don't.
Given enough time, I believe they are all going to come up with the
same interface, feature set, and maybe slightly different backends.
So why shouldn't we just short circuit this process and all the user
hassle that will result during the process of that happening?
If i actually believed there was really room for tons of innovation
here, i would probably lean towards your side of the argument. But
every implementation of changelists in a non-distributed VCS (what we
are referring to as changelists) seems to come to the same end so far.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Mark Phippard <ma...@gmail.com>.
On 1/16/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
>
> Hm, those are very good points, Karl.
>
> I was originally going to reply that you and CMike were both sort of
> throwing shadows, giving fuzzy arguments that "in your gut" this
> implementation wouldn't lead us down the path we wanted. My reply
> would have been along the lines of quoting ghudson ("don't let the
> perfect become the enemy of the good").
>
> But you're right, using scattered entries files as a database is a
> pretty poor design. And yeah, it makes it hard to implement
> overlapping changesets. I probably wasn't noticing this problem
> because all of the subcommands that filter on the new label are doing
> recursive walks anyway... but there are many other uses for
> changelists, and a client application shouldn't *have* to do a
> recursive walk just to know who a changelist's members are. Yuck.
> That's really restrictive.
>
> So, I concede. I just wish that, you know, somebody had been paying
> attention to my commits all last May. A simple "don't do it that way"
> would have saved a lot of time and backtracking. :-) Back then, we
> spent a long while hashing out the use-cases and UI (in
> notes/changelist-design.txt), but no time discussing underlying
> implementation. Seems like the design file is still good, but the
> implementation is not.
I do not know if this will add to the conversation or not. But the subject
of other SVN clients has been brought up, so I think it might be relevant.
I just wanted to point out that Subclipse has had support for "Change Sets"
for a while now. It is rooted in an Eclipse feature that they provide for
CVS, but expose as a generic API for all "Team" providers. Eclipse contains
a common "Synchronize" view that you can use to update/commit from.
Basically a graphical version of svn status -u. I have posted links to a
screenshot before:
http://subclipse.tigris.org/images/sync-ss.png
Anyway, this view also contains UI to support change sets. We just had to
do the necessary work in Subclipse to drive the view and make it all work
correctly. Basically, you can group files into change sets, and write/save
the commit message associated with the change set. You can then commit when
you want to. There is also an "incoming" component to this, where the
changes that need to come in from the repository can be grouped by change
set, which is just the revision and log message for that revision in the
case of SVN. A file changed multiple times only shows in the latest
grouping. I do not want to get too off topic but there is another Eclipse
plugin called Mylar that adds another dimension to this and lets you work in
a task focused UI. This automatically creates change sets for the tasks you
are working on, and populates the change set with files as you change them
while a task is "active". It is very cool and lets you open/close entire
sets of editors by activating or deactivating a task you are working on.
All integrated with Bugzilla, IssueZilla etc...
I could put together something for my blog with more screen shots if it
would help.
Getting back on topic, we did not need any new or special API's to implement
this. I do not have any need or plans to move it over to the new feature in
SVN either, as the only benefit would be to move between clients. In this
case, that does not feel overly critical feature to have.
Obviously to support "hunks" would require API support, unless we were going
to really change our philosophy in Subclipse and manipulate the WC with our
own code.
I am not against this feature being added to the command line. I view the
CLI as a UI, and this is its implementation. The fact that the CLI has this
feature does not prevent Subclipse from having its own, and it gives is an
option to reuse it if that is the best way to do it.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Hm, those are very good points, Karl.
I was originally going to reply that you and CMike were both sort of
throwing shadows, giving fuzzy arguments that "in your gut" this
implementation wouldn't lead us down the path we wanted. My reply
would have been along the lines of quoting ghudson ("don't let the
perfect become the enemy of the good").
But you're right, using scattered entries files as a database is a
pretty poor design. And yeah, it makes it hard to implement
overlapping changesets. I probably wasn't noticing this problem
because all of the subcommands that filter on the new label are doing
recursive walks anyway... but there are many other uses for
changelists, and a client application shouldn't *have* to do a
recursive walk just to know who a changelist's members are. Yuck.
That's really restrictive.
So, I concede. I just wish that, you know, somebody had been paying
attention to my commits all last May. A simple "don't do it that way"
would have saved a lot of time and backtracking. :-) Back then, we
spent a long while hashing out the use-cases and UI (in
notes/changelist-design.txt), but no time discussing underlying
implementation. Seems like the design file is still good, but the
implementation is not.
* Should I start by reverting my 3 or 4 revisions?
* Is anyone interested in coming up with a better implementation in
the commandline client? Working with me?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Karl Fogel <kf...@red-bean.com>.
On 1/16/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> You're saying that the argument for factorization "doesn't apply as
> well" to this feature, and therefore we should do any factorization
> *at all*?
Well, not really. That's part of my argument, but not the whole
of it...
> To keep track of changelists, one needs to do some bookkeeping... just
> associate a name with a list of files. You're advocating that every
> single client app create some sort of private database to do this?
> But wait... we already *have* a database of sorts... the entries file!
> It's sitting right there, in front of every app. It's utterly
> trivial to store a label in an svn_entry_t.
>
> So that's exactly the API I wrote: (1) an API to add/remove a
> changelist label from a path (by adding/removing it from the
> underlying svn_entry_t). (2) an API to search the working copy for
> all paths matching a changelist. Basic database functionality,
> nothing more.
And really poor database functionality, from an indexing standpoint.
Even though users almost always deal with changesets by name,
SVN has to reach them backwards: to reconstruct changelist X,
we ask every file if it's in X, instead of asking X what files are in it!
In large working copies, this isn't great... :-)
> I think you are vastly overestimating the complexity of the existing
> code. It's nothing more than an extra field in svn_entry_t, and
> teaching some svn_client_* APIs to filter on that field. The "hard"
> stuff -- like UI -- already rests squarely at the application level,
> exactly where you think it should be.
>
> (Does the current commandline UI stink? Maybe? Then let's fix the
> commandline client. Let's encourage TortoiseSVN to do something cool
> and GUI-like. AFAICT, no client has been hindered here by the
> existing code, only helped.)
The issue is not that other clients are hindered, nor is it that the
current library *code* is too complex. The issue is about APIs:
every time we add something, we're stuck with it, and my instinct
is that down the road we're going to regret these interfaces --
"regret" in the sense that, as clients figure out what they really
want from changelists, the APIs we added now will turn out to
be slightly off from what's needed. Sure, we can add whatever
the clients need later, and just have some old cruft in our APIs
that no one uses. Small prices, paid repeatedly, add up, that's all.
(I think your point about the library changes being really tiny cuts
both ways. If they're small, then the benefits of supplying them
for all clients can't be that large either.)
Here's another concrete example of where I think the current libsvn_wc
changes will fall down:
The svn_wc_entry_t 'changelist' field is only meant to hold one changelist
name. There's no way to compatibly store multiple changelist names
in .svn/entries right now (so much for a general-purpose database). Yet
overlapping changesets are surely in the future of this feature, especially
when hunk-level selection gets implemented! And once people start doing
stuff like that, even if we *could* keep all the information in .svn/entries, we
probably wouldn't want to.
So, no, I don't think we're creating a good foundation for the future. If
we absolutely *must* provide library-level support, I wish we'd do it
in the configuration area code instead of libsvn_wc, so that we could
at least index changesets in a conceptually appropriate way, with both
proper performance and proper semantics.
I'm sorry to sound like such a spoil sport about it. I like the feature,
I just think you may be so close to the particular implementation you
did that its problems don't jump out at you. I hope the two concrete
criticisms above help clarify the point I'm trying to make.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 1/16/07, Karl Fogel <kf...@red-bean.com> wrote:
> "Aha", I hear someone object, "But why make all the different clients
> implement this, when we could implement it in Subversion and save
> them the trouble / make the feature consistent / do it most efficiently /
> etc?"
>
> That argument doesn't apply as well to the changelist feature as it might
> to other features. Changelists are all about interface anyway -- most of
> what's involved in getting this feature right falls on the interface side of
> the code. The rest is trivial, because it just involves passing lists of files
> to existing Subversion library APIs. All those APIs already *take* lists
> of files. You want 'svn diff' to be changelist-sensitive? Well, if your
> client is changelist-conscious, it'll just pass the files of the currently-
> active changelist when it invokes the diff APIs. It's not like tons
> of potential
> client code is getting factored away by us putting this directly in Subversion;
> most of what clients would have had to write, they'd still have to write.
I think you've gone a touch off the deep end here. :-)
You're saying that the argument for factorization "doesn't apply as
well" to this feature, and therefore we should do any factorization
*at all*?
To keep track of changelists, one needs to do some bookkeeping... just
associate a name with a list of files. You're advocating that every
single client app create some sort of private database to do this?
But wait... we already *have* a database of sorts... the entries file!
It's sitting right there, in front of every app. It's utterly
trivial to store a label in an svn_entry_t.
So that's exactly the API I wrote: (1) an API to add/remove a
changelist label from a path (by adding/removing it from the
underlying svn_entry_t). (2) an API to search the working copy for
all paths matching a changelist. Basic database functionality,
nothing more.
All the rest is svn-commandline client UI stuff, just as you
suggested. 'svn status' showing changelists? That's entirely in the
commandline client. The whole 'svn changelist blah blah' command?
Entirely in the commandline client.
The only other API tweaks I made were some optional new 'changelist'
arguments to svn_client_commit() and svn_client_revert(), so that
these existing APIs could do internal filtering on a changelist name.
But heck, if you feel strongly about it, I could undo those changes,
and just let every client application extract the changelist paths,
and then pass the whole path-list directly into these functions.
Though once again, if *every* application has to do that same task, it
makes one ask: why isn't the API doing the filtering itself? Why not
factorize? I don't think these extra arguments to commit and revert
are dictating fundamental UI decisions to applications.
I think you are vastly overestimating the complexity of the existing
code. It's nothing more than an extra field in svn_entry_t, and
teaching some svn_client_* APIs to filter on that field. The "hard"
stuff -- like UI -- already rests squarely at the application level,
exactly where you think it should be.
(Does the current commandline UI stink? Maybe? Then let's fix the
commandline client. Let's encourage TortoiseSVN to do something cool
and GUI-like. AFAICT, no client has been hindered here by the
existing code, only helped.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Michael Haggerty <mh...@alum.mit.edu>.
Karl Fogel wrote:
> On 1/16/07, Daniel Rall <dl...@collab.net> wrote:
>> The typical case where I require overlapping change sets is for a
>> refactoring opportunity or requirement encountered while working on
>> some other feature. For example, while working on JavaHL's logging
>> code, I suddenly realize that in an error situation I need to throw a
>> specific type of exception, for the case where the logging code is
>> invoked from JavaHL's the SVNAdmin class instead of its SVNClient
>> class. Unfortunately, previous to r22985, JavaHL's exception factory
>> code would only throw ClientException. So I refactor the code to
>> allow me to specify the exception type to throw. Unfortunately, both
>> the logging code and the exception factory code are in the JNIUtil C++
>> class! So the change that I started making first needs to be
>> committed second, and depends on another change in the same file I
>> completed while working on the initial change.
>
> This is the common case for me, too. I often have multiple changesets
> running at once (I mean conceptual changesets -- not using the
> "changelist" featue, just squirreling away patches and doing the CMike
> workaround). This is usually because while working in a file to solve
> problem A, I encounter problem B, and then in the course of solving
> B encounter C, etc. Naturally, A, B, and C all deserve separate commits.
This is also my work flow.
Are you guys familiar with the tool called "quilt"?
http://savannah.nongnu.org/projects/quilt/
http://www.suse.de/~agruen/quilt.pdf
It is *almost* a very cool tool, but in combination with SVN I think it
would be a very good model for solving the changeset problem in a more
general and more natural way than the changelist feature that is being
discussed.
I haven't worked very much with quilt, but I'll nevertheless try to
provide a brief sketch of how it works followed by how an SVN + quilt
system could work.
<brief-sketch-of-quilt>
Quilt manages an ordered list of N named patches (aka changesets). At
any given moment, the first n <= N patches are applied to your working
copy and the top applied patch is active:
clean-up-docs.diff <- this patch is not currently applied
fix-segfault.diff <- this patch is not currently applied
add-pool-argument.diff <= the top applied patch
replace-array-with-map.diff <- this patch is applied
error-refactoring.diff <- this patch is applied
Quilt talks about a stack of patches, with commands "quilt push" and
"quilt pop" to apply patch n+1 or un-apply patch n, respectively. These
commands record what is the new "top" patch and by default they refuse
to apply a patch that does not apply cleanly. Even if you have edited
the working copy, you can still push/pop patches as long as they apply
cleanly.
What you can do with quilt is manage and modify patches very dynamically.
If you want to improve a patch before committing it, all you have to do
is bring it to the top of the stack, edit the WC, then type "quilt
refresh". This command changes the top patch to include its old
contents plus the changes to the working copy.
You can create a new patch at the top of the stack by typing "quilt new
<patch-name>". The new patch starts out empty.
There are lots more commands that do more-or-less obvious things: "quilt
diff", "quilt import", "quilt delete", etc.
</brief-sketch-of-quilt>
quilt has one very annoying failing: you have to tell it what files you
want to modify as part of a patch *before* modifying them. Otherwise it
gets hopelessly confused in a way that is awkward to fix.
Wouldn't it be cool if svn would support the following sequence of actions:
$ svn co $URL
Start editing some files, then realize that there's something you want
to change before your half-done changes.
$ svn newpatch "myfeature"
$ svn refreshpatch
$ svn poppatch
At this point your WC is in virgin state again, with a patch called
"myfeature" tucked away in the .svn directories somewhere. Now you
start editing files to implement the new new pre-feature.
# Verify that pre-feature works:
$ ./run-tests
# Pack it up as a patch, not yet committed:
$ svn newpatch "prefeature"
$ svn refreshpatch "prefeature"
# Apply the half-finished "myfeature" patch on top of "prefeature":
$ svn pushpatch
At this point you have two live changesets, both applied to the WC. The
top (active) patch is "myfeature". You edit files to complete the
implementation of "myfeature", then
# Verify that the current WC is not broken:
$ ./run-tests
# Store the complete changes to the "myfeature" patch:
$ svn refreshpatch "myfeature"
# Get ready to commit upstream:
$ svn poppatch --all
# Optionally update before commit:
$ svn update
# Commit "prefeature":
$ svn pushpatch
$ svn commitpatch -m "Pre-feature description"
(this would probably mark your "prefeature" patch as obsolete)
# Commit "myfeature":
$ svn pushpatch
$ svn commitpatch -m "My feature description"
Some other things that would be very cool:
- Allow commit messages to be stored with patches, and edited whenever
the patch is active (quilt supports this).
- Allow multiple patches to be committed at once.
- Allow the order of patches to be swapped, provided they don't conflict.
- Allow a patch to be split in a sensible way. (For example, apply all
of the combined patch, then undo the things you don't want in the first
patch.)
- To synchronize a branch with trunk, download the missing changesets
from trunk into your patch set, then work through them one by one until
they all apply cleanly, then commit them all in one commit to the branch
a la svnmerge.py.
The amazing thing is that quilt is implemented as a bunch of shell
scripts--something like 5000 lines total. It really isn't rocket
science. (About the only technology we would need to get started with
this would be a format for storing diffs that include property changes.)
And quilt would be so much nicer if it were coupled with an SCM.
You might think that quilt is just a poor man's distributed SCM. But
the flavor of working with it is quite different, because patches are
very mutable until the moment that they are committed upstream. Try to
imaging all of the branching and merging stunts you would have to do to
"retroactively" improve a commit using a distributed SCM. With quilt it
is just a few trivial commands.
One key advantage of the quilt way of working compared to the changelist
model is that quilt recognizes that patches have to be kept in order to
be well-defined. Patches don't, in general, commute. If you
acknowledge the fact that patches' order has to be preserved, then it
becomes trivial to support changesets at a finer granularity than
file-level.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Karl Fogel <kf...@red-bean.com>.
On 1/16/07, Daniel Rall <dl...@collab.net> wrote:
> The typical case where I require overlapping change sets is for a
> refactoring opportunity or requirement encountered while working on
> some other feature. For example, while working on JavaHL's logging
> code, I suddenly realize that in an error situation I need to throw a
> specific type of exception, for the case where the logging code is
> invoked from JavaHL's the SVNAdmin class instead of its SVNClient
> class. Unfortunately, previous to r22985, JavaHL's exception factory
> code would only throw ClientException. So I refactor the code to
> allow me to specify the exception type to throw. Unfortunately, both
> the logging code and the exception factory code are in the JNIUtil C++
> class! So the change that I started making first needs to be
> committed second, and depends on another change in the same file I
> completed while working on the initial change.
This is the common case for me, too. I often have multiple changesets
running at once (I mean conceptual changesets -- not using the
"changelist" featue, just squirreling away patches and doing the CMike
workaround). This is usually because while working in a file to solve
problem A, I encounter problem B, and then in the course of solving
B encounter C, etc. Naturally, A, B, and C all deserve separate commits.
I'm not thrilled with the changelist feature as it stands, because I think
we've put into the libraries something that really belongs in purely client
code. For example, suppose I were using an Emacs interface to
Subversion. I could easily write the changelist feature without changing
a line of code in Subversion itself: just give my file-management interface
the ability to put files in groups and name the groups. Then later, when
I want to add hunk-level management, I just have Emacs start remembering
which hunks of a given file's "svn diff" output are included in a given
change group, and when committing, do the following: save the working diff
for the entire file, revert the file, pull out the appropriate hunks from the
saved diff, apply them to the working file, commit, then (re)apply the
remainder of the patch. Voilà! Hunk-level changelist control, and not a line
of code in Subversion affected.
The point here is not Emacs (or Eclipse, or TortoiseSVN, or 'svn', etc), of
course -- it's clients in general. *Everything* needed to implement any
reasonable definition of a changelist feature can be done purely in client
code. So why are we starting by doing it in the libraries?
"Aha", I hear someone object, "But why make all the different clients
implement this, when we could implement it in Subversion and save
them the trouble / make the feature consistent / do it most efficiently /
etc?"
That argument doesn't apply as well to the changelist feature as it might
to other features. Changelists are all about interface anyway -- most of
what's involved in getting this feature right falls on the interface side of
the code. The rest is trivial, because it just involves passing lists of files
to existing Subversion library APIs. All those APIs already *take* lists
of files. You want 'svn diff' to be changelist-sensitive? Well, if your
client is changelist-conscious, it'll just pass the files of the currently-
active changelist when it invokes the diff APIs. It's not like tons
of potential
client code is getting factored away by us putting this directly in Subversion;
most of what clients would have had to write, they'd still have to write.
And taking the long view, we're failing to take advantage of "the laboratory
of the clients" by stuffing this into Subversion now. Even if it eventually
makes sense to have changelist support directly in Subversion, I think we'd
find out how to do it best by seeing how lots of clients implement it, and
adjusting our APIs to support their needs first.
If we're going to ship native Subversion with changelists, can't we put them
in the 'svn' client first (it can use the config area for bookkeeping), and not
make irreversible changes to our APIs and the .svn/entries file? Then we're
just another client, and we can experiment with stuff without worrying about
permanently mucking up our APIs.
None of this is an objection to the feature itself, by the way. I love
changelists, they're great, they make the sun shine and the grass grow
and the mitochondria oxidize. Yay, changelists.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 16 Jan 2007, Ben Collins-Sussman wrote:
> 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'.
Yeah, this is the opposite of my working style. I typically have a
bunch of changes going at once across several WCs. Personally, I
consider it bad practice to type 'svn commit' with no explicit
targets, as an urge to do that often means that I haven't done enough
pre-commit review of my changes.
> 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.
Hmmmmm. With the state of today's tool set (including the changelist
feature), it's best to keep related changes segregated in separate
working copies to avoid unexpected side-effects when commiting one
change set without another. Strictly speaking, it's the *unrelated*
changes with unexpected side-effects which makes separate WCs a better
idea.
> 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.
...
> - 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.
The --targets option handles roughly half the features provided by
today's changelist implementation. How --targets is intended to be
used isn't perfectly clear, though:
$ svn help ci | grep 'targets arg '
--targets arg : pass contents of file ARG as additional args
It would be nice if either --targets or changelist was implemented
consistently across commands, and if there was a more clear
distinction on when to use what, and what --targets was really
intended to do (since it sounds like you can use it to pass arbitary
arguments).
...
> * 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.)
Because I often have the need for overlaping changelists, I don't find
the changelist feature as implemented today a meaningful enough
improvement over --targets. However, I would like to see it become
so!
While I agree that overlapping change sets *should* be developed
serially, my experience shows that in the majority of cases where I
have overlap, that the need for serial development is not apparent
soon enough in the development cycle to avoid the overlap. The
combination of the need for overlapping change sets and the frequency
which I find they occur tells me that we haven't solved 90% of the use
cases (I'd say more like 50%, between lack of support for overlapping
change sets, and lack of comprehensive changelist support across
sub-commands).
The typical case where I require overlapping change sets is for a
refactoring opportunity or requirement encountered while working on
some other feature. For example, while working on JavaHL's logging
code, I suddenly realize that in an error situation I need to throw a
specific type of exception, for the case where the logging code is
invoked from JavaHL's the SVNAdmin class instead of its SVNClient
class. Unfortunately, previous to r22985, JavaHL's exception factory
code would only throw ClientException. So I refactor the code to
allow me to specify the exception type to throw. Unfortunately, both
the logging code and the exception factory code are in the JNIUtil C++
class! So the change that I started making first needs to be
committed second, and depends on another change in the same file I
completed while working on the initial change.
You could (accurately) claim that I should've noticed this requirement
up front, noted the dependency, and implemented the changes in the
correct order. But let's be realistic here -- how often do you really
get perfect requirements?!
> * 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.)
I'm curious about this, too.
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by John Peacock <jp...@rowman.com>.
John Peacock wrote:
> Ben Collins-Sussman wrote:
>> Perhaps we should ask the svk guys? Last I heard, svk actually has a
>> feature to manage patch-hunks for you. Or at least, when you merge
>> changes, it can interactively ask you questions about each hunk... I
>> wonder if it allows you to name sets of hunks, and commit specific
>> hunks as well?
FWIW, I've just tested and indeed --interactive prompts for each chunk and
--patch creates a patch file containing just those chunks that I said to use
during the interactive phase. The working copy remains completely unchanged and
the "commit" message is saved as the log message portion of the patch file itself.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Blvd
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by John Peacock <jp...@rowman.com>.
Ben Collins-Sussman wrote:
> Perhaps we should ask the svk guys? Last I heard, svk actually has a
> feature to manage patch-hunks for you. Or at least, when you merge
> changes, it can interactively ask you questions about each hunk... I
> wonder if it allows you to name sets of hunks, and commit specific
> hunks as well?
That would be 'svk ci --interactive'
interactively select which "chunks" to commit
and '--patch NAME'
instead of commit, save this change as a patch
which I've never used together, but it would appear would allow you to
have changelist functionality at the hunk level. I'll try that tonight,
if I get the chance...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 1/16/07, C. Michael Pilato <cm...@collab.net> wrote:
> I think you're using "minor/major" to mean common/uncommon, where I was
> using it to mean trivial/complex. I'm not claiming that the feature
> doesn't do what it was intended to do. I merely expressed that there
> are other ways to do it, and wondered aloud if the balance between the
> convenience of having Subversion do it and the cost of maintaining the
> design and implementation long-term had been properly struck.
Ah, yes, understood, and I agree. Every new feature has to strike
that balance, and as a developer community we've always been pretty
paranoid about evaluating things in that light. For that reason, I
designed the feature to be *very* simple in its implementation and
UI... so as to counterbalance the fact that it's solving a very
common, not-very-complicated problem. I don't want to swat a fly
with a Buick.
>
> From what I'm reading about the implementation, though, it seems pretty
> simple, which lowers the bar for the utility the feature needs to
> provide in order to be "worth it". As such, I'm not in opposition to
> it. I'd forgotten, too, that eventually --changelist was code as a
> filter, not a harvester, which is significantly less complicated and a
> much cleaner UI.
Cool.
> I, Mike Pilato, user of Subversion, sure do wish Subversion could
> squirrel away and retrieve uncommitted changesets-in-progress with
> sub-file granularity so I could have changesets that overlap.
>
> :-)
:-)
I agree it would be nice, but I feel like it would take months and
months to write such a feature, all to solve a use-case that's pretty
uncommon. I feel like it doesn't strike a good balance: tons of
work, not a whole lot of benefit. As I said before, if two
changesets-in-progress really affect the same file, it's also quite
likely that the changesets probably shouldn't be developed in parallel
anyway. So I guess on a personal level, I don't feel very strongly
about this itch.
>
> My concern about the existing feature complicating the one I actually
> want follows strictly from the belief that it is extremely unlikely that
> UI added for your changelist feature will be sufficient to also cover
> that advanced functionality. I'd feel better knowing that someone had
> at least considered what such a UI might look like so we're less likely
> to have to shim in additional, less natural command-line options later.
> Since you apparently weren't even thinking about the more advanced
> feature, it seems unlikely that you can offer that peace of mind. But
> then again, if we've no plans to go down that path in the future, it
> hardly matters.
Perhaps we should ask the svk guys? Last I heard, svk actually has a
feature to manage patch-hunks for you. Or at least, when you merge
changes, it can interactively ask you questions about each hunk... I
wonder if it allows you to name sets of hunks, and commit specific
hunks as well?
>
> SIDEBAR: Claiming that changing the same file for different changesets
> is a bad practice, but changing multiple files for different changesets
> isn't, is a bit of a bogus argument that lives and dies on your
> assumptions about the relationships between the lines of a file to one
> another and of one file to another file. [...]
Ah, I'm not saying that changing the same file for different
changesets is an inherently bad practice, just that it's *likely* to
be two changesets that are better off being developed in serial. I
agree that there are plenty of counterexamples; I'm only arguing that
they're not the norm.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Ben Collins-Sussman wrote:
> 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.)
I think you're using "minor/major" to mean common/uncommon, where I was
using it to mean trivial/complex. I'm not claiming that the feature
doesn't do what it was intended to do. I merely expressed that there
are other ways to do it, and wondered aloud if the balance between the
convenience of having Subversion do it and the cost of maintaining the
design and implementation long-term had been properly struck.
From what I'm reading about the implementation, though, it seems pretty
simple, which lowers the bar for the utility the feature needs to
provide in order to be "worth it". As such, I'm not in opposition to
it. I'd forgotten, too, that eventually --changelist was code as a
filter, not a harvester, which is significantly less complicated and a
much cleaner UI.
> * 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.)
Don't assume that users voice every desire they might have for a piece
of software. But if it makes you feel better:
I, Mike Pilato, user of Subversion, sure do wish Subversion could
squirrel away and retrieve uncommitted changesets-in-progress with
sub-file granularity so I could have changesets that overlap.
:-)
My concern about the existing feature complicating the one I actually
want follows strictly from the belief that it is extremely unlikely that
UI added for your changelist feature will be sufficient to also cover
that advanced functionality. I'd feel better knowing that someone had
at least considered what such a UI might look like so we're less likely
to have to shim in additional, less natural command-line options later.
Since you apparently weren't even thinking about the more advanced
feature, it seems unlikely that you can offer that peace of mind. But
then again, if we've no plans to go down that path in the future, it
hardly matters.
SIDEBAR: Claiming that changing the same file for different changesets
is a bad practice, but changing multiple files for different changesets
isn't, is a bit of a bogus argument that lives and dies on your
assumptions about the relationships between the lines of a file to one
another and of one file to another file. For example, tweaking the
parameter list for two functions whose implementations live in different
files, but whose prototypes happen to live in the same .h file, doesn't
mean those changes are *really* any more closely related than if their
prototypes lived in separate locations.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
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
Re: changelist feature -- keep it? tweak it? scrap it?
Posted by David Anderson <da...@natulte.net>.
On 1/16/07, C. Michael Pilato <cm...@collab.net> wrote:
> If the community is cool with the feature as it stands, fantastic.
> Obviously, this isn't MikeVersion. But I just don't get the impression
> that the votes for it thus far have been anything other than +/-0. Is
> anyone using this feature?
I didn't really feel the need for changelists until very recently,
when I started using perforce. Since then, almost every time I do
development on a Subversion based project with a stable client, I
realize at some point or another that I'm typing `svn ci <long list of
files>` to cherrypick some of my changes to commit. Being able to
visualize these changesets in my working copy just rocks (most
importantly to me, `svn diff` of just what I want).
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org