changelist feature in trunk, for toying with

[Ben Collins-Sussman <su...@red-bean.com>]

Hi folks,

I wanted to point out that I've merged my changelist-feature branch to
trunk, so that you can play around with it now.

I hope this doesn't alarm anybody;  I'm not trying to railroad this
feature through!  On the one hand, people who haven't been paying
attention to previous discussions may be wondering "where'd that come
from?"  On the other hand, I've tried to be as open about the process
as possible:

  * I proposed a feature, there was a lot of discussion with almost
entirely positive feedback and enthusiasm for the idea.

  * I then did the work on the branch, so as not to destabilize a
pending 1.4 release, and to let people watch the ideas evolve.  I
received some simple commit reviews, mainly from Philip Martin.

  * I committed a design document and asked for feedback;  again, just
a few positive responses to the ideas.

  * Now that there's something to play with (and 1.4 is branched), I
merged the code to trunk.

To be clear:  my merging to trunk is not some sort of trick for making
the feature 'official' by force of will.  I think it's just the next
step in the process.  There's enough code written now for people to
try it out, further criticize it, and so on.  The fact is, when
something is in a branch it basically doesn't exist.  (For example,
all of dlr and dannyb's work on merge tracking seems like only a
fantasy to me. :-) )  And some big fans of the feature (dlr, dannyb)
have been  waiting for me to produce something they can play with.

So, if anyone feels like I've crossed a line, let me know, and I'll
take the stuff back to a branch!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: changelist feature in trunk, for toying with

[Daniel Rall <dl...@collab.net>]

On Mon, 03 Jul 2006, David Glasser wrote:

> On 7/3/06, Ben Collins-Sussman <su...@red-bean.com> wrote:
> >On 7/3/06, David Glasser <gl...@mit.edu> wrote:
> >> Specifically, the changelist (in the currently proposed/implemented 
> >design) is
> >> fundamentally *not* a list of changes: it's a list of files.   The name 
> >"change
> >> list" implies to me that it applies at the level of individual hunk 
> >changes, not
> >> at the file-level granularity.
> >
> >That would be a 'patch', right?  A collection of hunk changes?  :-)
> 
> Heh.  The point I was trying to make is that you (with good reason)
> aren't worrying about dealing with "overlapping changelists", which is
> easier to understand if the feature is called something like "path
> list" instead of "changelist".

As with Mike, I very often -- ~60% of the time -- have multiple change
sets which overlap a single file.  I would like to see the changelist
feature evolve (for files) to handle hunk or line number
identification within a single file.  Using a more generic term like
"changelist" works well with that direction.

Re: changelist feature in trunk, for toying with

[David Glasser <gl...@mit.edu>]

On 7/3/06, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On 7/3/06, David Glasser <gl...@mit.edu> wrote:
> > Specifically, the changelist (in the currently proposed/implemented design) is
> > fundamentally *not* a list of changes: it's a list of files.   The name "change
> > list" implies to me that it applies at the level of individual hunk changes, not
> > at the file-level granularity.
>
> That would be a 'patch', right?  A collection of hunk changes?  :-)

Heh.  The point I was trying to make is that you (with good reason)
aren't worrying about dealing with "overlapping changelists", which is
easier to understand if the feature is called something like "path
list" instead of "changelist".

> It's not just a list of files, it's a list of paths.  Paths can be
> files or dirs.

Good point.

> I think the reason we've latched onto the term 'changelist' here is
> because we're picking up the word from perforce.  In fact, we're flat
> out copying a lot of this idea from perforce, so we're trying to keep
> momentum with the huge number of perforce users out there.
>
> Take a look at the designdoc in notes/.  Does it make things clearer?

Right; I understand that developers coming from Perforce are probably
looking for this feature under the name of changelist.  I just wanted
to get the idea out there that folks *not* coming from Perforce might
find the name to be strange.  If nobody else thinks the same thing as
me, then that's a moot point though :)

--dave

-- 
David Glasser | glasser@mit.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: changelist feature in trunk, for toying with

[Ben Collins-Sussman <su...@red-bean.com>]

On 7/3/06, David Glasser <gl...@mit.edu> wrote:
> Ben Collins-Sussman <sussman <at> red-bean.com> writes:
>
> > I wanted to point out that I've merged my changelist-feature branch to
> > trunk, so that you can play around with it now.
>
> I think this is a great feature and one I would use.  At the risk of
> bikeshedding, I have to say that as a user, I think I would find the name
> "changelist" confusing.
>
> Specifically, the changelist (in the currently proposed/implemented design) is
> fundamentally *not* a list of changes: it's a list of files.   The name "change
> list" implies to me that it applies at the level of individual hunk changes, not
> at the file-level granularity.

That would be a 'patch', right?  A collection of hunk changes?  :-)


> In addition, my intuitive guess as to what "svn
> changelist foo bar.c baz.h" would do would be to record *the current changes* in
> bar.c and baz.h into "foo", not just their names.  In addition, "changelist"
> sounds very close to the concept of "changeset" from other SCMs which Subversion
> basically rolls into "revision".
>
> Obviously reading the documentation would set me straight here; however, I think
> that using a name that doesn't actually describe what the feature actually is is
> confusing.  I think using a name like "file set" or something would be much more
> descriptive than "changelist".

It's not just a list of files, it's a list of paths.  Paths can be
files or dirs.

I think the reason we've latched onto the term 'changelist' here is
because we're picking up the word from perforce.  In fact, we're flat
out copying a lot of this idea from perforce, so we're trying to keep
momentum with the huge number of perforce users out there.

Take a look at the designdoc in notes/.  Does it make things clearer?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: changelist feature in trunk, for toying with

[David Glasser <gl...@mit.edu>]

Ben Collins-Sussman <sussman <at> red-bean.com> writes:

> I wanted to point out that I've merged my changelist-feature branch to
> trunk, so that you can play around with it now.

I think this is a great feature and one I would use.  At the risk of
bikeshedding, I have to say that as a user, I think I would find the name
"changelist" confusing.

Specifically, the changelist (in the currently proposed/implemented design) is
fundamentally *not* a list of changes: it's a list of files.   The name "change
list" implies to me that it applies at the level of individual hunk changes, not
at the file-level granularity.  In addition, my intuitive guess as to what "svn
changelist foo bar.c baz.h" would do would be to record *the current changes* in
bar.c and baz.h into "foo", not just their names.  In addition, "changelist"
sounds very close to the concept of "changeset" from other SCMs which Subversion
basically rolls into "revision".

Obviously reading the documentation would set me straight here; however, I think
that using a name that doesn't actually describe what the feature actually is is
confusing.  I think using a name like "file set" or something would be much more
descriptive than "changelist".

--dave

glasser@mit.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org