You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@red-bean.com> on 2006/04/17 18:10:04 UTC
proposal: changelist feature
Hi folks, it's been a while since I worked on subversion coding
project. This is a proposal for a new client-side feature I'd like to
work on. (For svn 1.5, obviously, not 1.4).
It's vaguely based on a similar feature in perforce, and it's
something a few of us have gotten used to since working at Google -- a
nice convenience.
In a nutshell, it's a way to attach temporary names to groups of
edited files in a working copy. If you've ever been working on
several different patches or tasks at the same time, it's easy to get
them confused. Perforce allows you to give a name to a set of files,
called a 'changelist'.
* 'svn status' would not only show local files as modified or
scheduled for addition/deletion, but also which changelist each
path belongs to. (Assuming you've bothered to assign changed
paths to changelists.)
* Anytime one might normally use a list of local paths on the
commandline, one could use a changelist name instead. For
example, one could revert, diff, or commit a changelist name.
* The only new UI-syntax we'd need is
- the ability to associate (or deassociate) a local path with a
changelist name
- a new commandline option to specify a changelist name.
Here's an imaginary demo of what this feature might be like.
---------------------------------
$ cd wc
$ echo "new text" >> foo.c
$ touch bar.c; svn add bar.c
A bar.c
$ svn st
M foo.c
A bar.c
$ svn changelist issue-2899 foo.c bar.c
foo.c is is now part of changelist 'issue-2899'.
bar.c is is now part of changelist 'issue-2899'.
$ svn st
Changelist 'issue-2899':
M foo.c
A bar.c
$ echo "blah" >> baz.c
$ svn st
M baz.c
Changelist 'issue-2899':
M foo.c
A bar.c
$ svn changelist feature-baz baz.c
baz.c is is now part of changelist 'issue-2899'.
$ svn st
Changelist 'feature-baz':
M baz.c
Changelist 'issue-2899':
M foo.c
A bar.c
$ svn diff --changelist issue-2899
(diffs for foo.c and bar.c are shown)
$ svn rm glorb.h
D glorb.h
$ svn changelist feature-baz glorb.c
svn: error: glorb.c isn't edited or scheduled.
$ svn changelist feature-baz glorb.h
glorb.h is is now part of changelist 'feature-baz'.
$ svn st
Changelist 'feature-baz':
M baz.c
D glorb.h
Changelist 'issue-2899':
4 M foo.c
A bar.c
$ svn changelist issue-2899 glorb.h
glorb.h is is now part of changelist 'issue-2899'.
$ svn st
Changelist 'feature-baz':
M baz.c
Changelist 'issue-2899':
M foo.c
A bar.c
D glorb.h
$ svn commit --changelist issue-2899
Adding bar.c
Sending foo.c
Deleting glorb.h
Transmitting file data..
Committed revision 23489.
-------------------------------
How this is different than perforce:
In perforce, the server tracks *every* working copy. In fact, working
copy files are read-only, and you need to tell the server you want to
edit them before they become read-write. Ergo, changelists are
entirely tracked by the server. On the one hand, this makes commands
like 'status' or 'commit' super-quick: instead of needing to crawl the
working copy for changes, a quick network request to the server
returns all the changed paths. On the other hand, this sort of thing
is only possible with a system designed for a LAN. Subversion is
WAN-based, so I'd never advocate that sort of design.
An initial super-simple implementation of such a feature could be
nothing more than attaching a changelist name as an 'entry-prop' in
.svn/entries, or something similar. Later on, if we wanted to get
fancy and try to make the svn client also be "super quick" and avoid
crawls, we *could* have the client track changelists in a central
registry, such as in ~/.subversion/. Of course, the tradeoff is that
it takes us one more step towards the idea of working copies being
non-divisible and non-portable. Not sure we want to open that
discussion. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Branko Čibej <br...@xbc.nu>.
Tim Hill wrote:
> Some questions/issues:
>
> 1. As another has asked, can a file be in more than one changelist? If
> so, what are the implications for checkin?
Sounds like local branches. :)
> 2. Presumably some means would be needed to edit changelists,
> including removing files from lists and/or deleting them?
>
> 3. Presumably, a changelist vanishes when it's checked-in? But if we
> allow a file in >1 changelist, what happens when the changelist is
> pre-empted by other checkins (e.g. list1 contains files A and B, list2
> contains B. Checkin list1, list2 is now an empty set???).
>
> 4. If this gets added, someone is going to want a way to tag (in the
> respository) the name of the changelist against the repo revision.
> Then someone will want to search on these. Then someone will notice
> that this is a back-door to revision labels, which everyone here seems
> to hate...... :(
I don't see that's necessary.AIUI the changelist idea is meant to help
developers, not impose some CM process. In the end you write a log
message anyway. (And yes, I *know* how hard it is to convince people to
write meaningful log messages. Sometimes I feel like the French at
Agincourt ...)
> I also have a more general workflow question: what is the problem
> being solved here? Are we looking at a scenario where several
> (possibly overlapping) changes are being worked on simultaneously?
I've personally been in situations where it would have come in handy --
I was keeping two or three unrelated patches in the same working copy,
and ended up duplicating the WC's instead. But the patches were fairly
small, and it always felt like overkill to burn several 100 MBs of disk
just to keep a few file changes separate.
> When I do this, I always handle it by creating distinct working
> copies, and then doing multiple checkins with merges as necessary.
> This also has the advantage of making each checkin atomic (with
> respect to features), even if the changes incolve overlapping files.
> The distinct WCs then act as, in effect, changelists all by
> themselves. Perforce cannot do this since it ties the WC and the
> server more closely than SVN.
-- Brane
Re: proposal: changelist feature
Posted by Tim Hill <ti...@realmgp.com>.
But there is a big difference between the changelist and multi-WC
approaches when handling overlapped edits.
Example: Two "issues" are being worked on. #1 involves changes to files
A and B, while #2 involves changes to files B and C. The same developer
is working on both issues.
Approach 1: Changelists:
Two changelists are created: CL1 contains files A and B, and CL2
contains B and C. The developer begins work on the issues, which
proceeds in parallel. So after some time, A is updated with issue #1
edits, B is updated with issue #1 and #2 edits, and C is updated for
issue #2.
The problem here is file B. It contains edits for both issues, and so I
*cannot* checkin CL1 or CL2 atomically. If I checkin CL1, then I also
get a *partial* CL2 update (via B but no C), and vice-versa for CL2. In
fact, I really have to checkin CL1 and CL2 if I want to keep the repo
coherent.
Approach 2: Multiple WCs:
Here, I create two WCs, one for issue #1, one for #2. Since they are
discreet, I have two copies of file B, and make changes to each copy
appropriate for each issue. A am then free to checkin from either WC
independently; the second of the two checkins will merge the changes
necessary for B. Notice that the repo is always coherent with respect to
the issues; either an issue is fully checked in or it is not.
Also notice that, in effect, the discreet WCs are acting in the role of
changelists anyway.
On a related issue, is there anything proposed that cannot be handled by
shell scripts? If I maintain a "changelist" as an external file with a
list of filenames, its trivial to hack a script that can submit this
list to an SVN COMMIT command? Are we really just talking about adding a
command-line syntax to work with "response files", i.e.:
svn commit @changelist
Where "changelist" is just a text file with the file names in it?
--Tim
Jared Hardy wrote:
> I'm new here and I'm not yet a submitter, but I was planning to
> implement a small Subversion Commit GUI in-house specifically to
> simulate Perforce-like change-lists for my users. I thought my input
> might be useful, if only because I deal with 10's of users on a daily
> basis that want to relocate to Perforce specifically for their fondness
> for change-lists.
> The point of change-lists for my users tends to be more a way to
> pre-organize atomic commits than any other reason. Being able to perform
> other actions, like Status or Updates on this list might be useful as
> well, but our main concern right now is making each atomic Commit fast
> and easy.
> My plan was to give them a simple interface for selecting a list of
> files pertaining to a planned Commit, the ability to give that Commit a
> title and description (description=log-message), and to "Save" the list
> without having to Commit. This file list, along with the title and
> description, would then be saved to a cache file, stored outside the
> working copy. On every Commit, they would have a drop-down list of these
> change-lists available, a "Commit attempt history" of sorts. This would,
> in our minds, take care of both the "Change-list" equivalent desire, and
> an even bigger complaint around here -- an interface more suitable to
> Commit recovery attempts when conflicts or other errors occur.
>
> Tim Hill wrote:
>
>> Some questions/issues:
>>
>> 1. As another has asked, can a file be in more than one changelist? If
>> so, what are the implications for checkin?
>>
>
> Yes files should be in more than one list, so I suggest change-lists be
> considered separate from the current WC status system. If not at a
> project root, they should be stored at a directory above all the paths
> the change-list contains. This would avoid some of the tree-walk
> problems mentioned before.
> I also suggest "svn status" stay the same, and instead some kind of
> keyword system be set up to indicate change-lists instead of paths or
> URLs. Perhaps change-lists could have their own URL-ish format, like
> "cl://bugfix9", to keep current svn syntax otherwise the same. Maybe
> just a "svn status --change-lists" command would have to be added, to
> show all current change-lists' status. Other commands, like "svn update
> cl://bugfix9" could use the same URL-ish syntax. The point is to deal
> with the file list as a single entity, not just to track status.
>
>
>> 2. Presumably some means would be needed to edit changelists, including
>> removing files from lists and/or deleting them?
>>
>
> Yes. We might even want to "merge" change-lists, to combine them into a
> new title. In my interface, this "add/remove" cycle would happen just by
> changing the selections on the file list without changing the title, and
> then hitting the "Save" button. Selections would automatically drop as a
> result of delete, moves, and renames when done after a change-list is
> created. In my system, it would be up to the user to keep the changelist
> aligned with such changes, but perhaps that is a flaw.
>
>
>> 3. Presumably, a changelist vanishes when it's checked-in?
>>
>
> Definitely not in our case. A programmer working on a specific tool
> would have a tendency to work on the same file list repeatedly, so being
> able to pull up the same change-list as a previous commit would be
> helpful. Maybe "historical" change-lists could be tracked separately
> from "current" change-lists, though. Think of it more like a multi-file
> bookmark than a current status list.
>
>
>> 4. If this gets added, someone is going to want a way to tag (in the
>> respository) the name of the changelist against the repo revision. Then
>> someone will want to search on these. Then someone will notice that this
>> is a back-door to revision labels, which everyone here seems to
>> hate...... :(
>>
>
> I would say, to keep things simple, the changelist title and description
> just become a natural part of the log message structure. It is rare that
> anyone would be interested in the change-lists of others, except where
> it conveys information about the intended consequences of an atomic
> commit, which the commit log message already serves. Otherwise, the real
> use is all local.
> I suppose those who work from more than one client may want to carry
> their "change-list cache" from one workstation to another. This just
> adds to the argument that change-lists should be centralized, rather
> than a per-file WC status item. I'm not even sure we would want to
> change the server for this at all.
>
> [snip]
>
>> I always handle it by creating distinct working copies, and then doing
>> multiple checkins with merges as necessary. This also has the advantage
>> of making each checkin atomic (with respect to features), even if the
>> changes incolve overlapping files. The distinct WCs then act as, in
>> effect, changelists all by themselves. Perforce cannot do this since it
>> ties the WC and the server more closely than SVN.
>>
>
> This brings up an interesting option for change-list use. My users are
> resistant to keeping multiple working copies (partly due to the
> non-recursive update issues mentioned in other threads), but they are
> interested in using branches in Subversion more like they did under
> Perforce. Each user would have their own branch, and would do all their
> daily commits to that branch, and merge their "user branch" with the
> trunk once or twice a week. That way, they feel like they're making
> their work available, without infecting the trunk with untested changes,
> nor being affected by others' changes. They want to keep their
> merge/test cycle less frequent than their commits. The change-list would
> help with this, as that would become a form of local history of their
> changes from the last trunk-merge, to keep them as a cohesive sets
> during their merge/test/trunk-commit cycles. We have been considering
> building custom clients with SVK for similar use.
>
>
> Thanks,
> Jared
>
>
Re: proposal: changelist feature
Posted by Jared Hardy <jh...@highimpactgames.com>.
I'm new here and I'm not yet a submitter, but I was planning to
implement a small Subversion Commit GUI in-house specifically to
simulate Perforce-like change-lists for my users. I thought my input
might be useful, if only because I deal with 10's of users on a daily
basis that want to relocate to Perforce specifically for their fondness
for change-lists.
The point of change-lists for my users tends to be more a way to
pre-organize atomic commits than any other reason. Being able to perform
other actions, like Status or Updates on this list might be useful as
well, but our main concern right now is making each atomic Commit fast
and easy.
My plan was to give them a simple interface for selecting a list of
files pertaining to a planned Commit, the ability to give that Commit a
title and description (description=log-message), and to "Save" the list
without having to Commit. This file list, along with the title and
description, would then be saved to a cache file, stored outside the
working copy. On every Commit, they would have a drop-down list of these
change-lists available, a "Commit attempt history" of sorts. This would,
in our minds, take care of both the "Change-list" equivalent desire, and
an even bigger complaint around here -- an interface more suitable to
Commit recovery attempts when conflicts or other errors occur.
Tim Hill wrote:
> Some questions/issues:
>
> 1. As another has asked, can a file be in more than one changelist? If
> so, what are the implications for checkin?
Yes files should be in more than one list, so I suggest change-lists be
considered separate from the current WC status system. If not at a
project root, they should be stored at a directory above all the paths
the change-list contains. This would avoid some of the tree-walk
problems mentioned before.
I also suggest "svn status" stay the same, and instead some kind of
keyword system be set up to indicate change-lists instead of paths or
URLs. Perhaps change-lists could have their own URL-ish format, like
"cl://bugfix9", to keep current svn syntax otherwise the same. Maybe
just a "svn status --change-lists" command would have to be added, to
show all current change-lists' status. Other commands, like "svn update
cl://bugfix9" could use the same URL-ish syntax. The point is to deal
with the file list as a single entity, not just to track status.
> 2. Presumably some means would be needed to edit changelists, including
> removing files from lists and/or deleting them?
Yes. We might even want to "merge" change-lists, to combine them into a
new title. In my interface, this "add/remove" cycle would happen just by
changing the selections on the file list without changing the title, and
then hitting the "Save" button. Selections would automatically drop as a
result of delete, moves, and renames when done after a change-list is
created. In my system, it would be up to the user to keep the changelist
aligned with such changes, but perhaps that is a flaw.
> 3. Presumably, a changelist vanishes when it's checked-in?
Definitely not in our case. A programmer working on a specific tool
would have a tendency to work on the same file list repeatedly, so being
able to pull up the same change-list as a previous commit would be
helpful. Maybe "historical" change-lists could be tracked separately
from "current" change-lists, though. Think of it more like a multi-file
bookmark than a current status list.
> 4. If this gets added, someone is going to want a way to tag (in the
> respository) the name of the changelist against the repo revision. Then
> someone will want to search on these. Then someone will notice that this
> is a back-door to revision labels, which everyone here seems to
> hate...... :(
I would say, to keep things simple, the changelist title and description
just become a natural part of the log message structure. It is rare that
anyone would be interested in the change-lists of others, except where
it conveys information about the intended consequences of an atomic
commit, which the commit log message already serves. Otherwise, the real
use is all local.
I suppose those who work from more than one client may want to carry
their "change-list cache" from one workstation to another. This just
adds to the argument that change-lists should be centralized, rather
than a per-file WC status item. I'm not even sure we would want to
change the server for this at all.
[snip]
> I always handle it by creating distinct working copies, and then doing
> multiple checkins with merges as necessary. This also has the advantage
> of making each checkin atomic (with respect to features), even if the
> changes incolve overlapping files. The distinct WCs then act as, in
> effect, changelists all by themselves. Perforce cannot do this since it
> ties the WC and the server more closely than SVN.
This brings up an interesting option for change-list use. My users are
resistant to keeping multiple working copies (partly due to the
non-recursive update issues mentioned in other threads), but they are
interested in using branches in Subversion more like they did under
Perforce. Each user would have their own branch, and would do all their
daily commits to that branch, and merge their "user branch" with the
trunk once or twice a week. That way, they feel like they're making
their work available, without infecting the trunk with untested changes,
nor being affected by others' changes. They want to keep their
merge/test cycle less frequent than their commits. The change-list would
help with this, as that would become a form of local history of their
changes from the last trunk-merge, to keep them as a cohesive sets
during their merge/test/trunk-commit cycles. We have been considering
building custom clients with SVK for similar use.
Thanks,
Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Tim Hill <ti...@realmgp.com>.
Some questions/issues:
1. As another has asked, can a file be in more than one changelist? If
so, what are the implications for checkin?
2. Presumably some means would be needed to edit changelists, including
removing files from lists and/or deleting them?
3. Presumably, a changelist vanishes when it's checked-in? But if we
allow a file in >1 changelist, what happens when the changelist is
pre-empted by other checkins (e.g. list1 contains files A and B, list2
contains B. Checkin list1, list2 is now an empty set???).
4. If this gets added, someone is going to want a way to tag (in the
respository) the name of the changelist against the repo revision. Then
someone will want to search on these. Then someone will notice that this
is a back-door to revision labels, which everyone here seems to
hate...... :(
I also have a more general workflow question: what is the problem being
solved here? Are we looking at a scenario where several (possibly
overlapping) changes are being worked on simultaneously? When I do this,
I always handle it by creating distinct working copies, and then doing
multiple checkins with merges as necessary. This also has the advantage
of making each checkin atomic (with respect to features), even if the
changes incolve overlapping files. The distinct WCs then act as, in
effect, changelists all by themselves. Perforce cannot do this since it
ties the WC and the server more closely than SVN.
--Tim
Ben Collins-Sussman wrote:
> Hi folks, it's been a while since I worked on subversion coding
> project. This is a proposal for a new client-side feature I'd like to
> work on. (For svn 1.5, obviously, not 1.4).
>
> It's vaguely based on a similar feature in perforce, and it's
> something a few of us have gotten used to since working at Google -- a
> nice convenience.
>
> In a nutshell, it's a way to attach temporary names to groups of
> edited files in a working copy. If you've ever been working on
> several different patches or tasks at the same time, it's easy to get
> them confused. Perforce allows you to give a name to a set of files,
> called a 'changelist'.
>
> * 'svn status' would not only show local files as modified or
> scheduled for addition/deletion, but also which changelist each
> path belongs to. (Assuming you've bothered to assign changed
> paths to changelists.)
>
> * Anytime one might normally use a list of local paths on the
> commandline, one could use a changelist name instead. For
> example, one could revert, diff, or commit a changelist name.
>
> * The only new UI-syntax we'd need is
>
> - the ability to associate (or deassociate) a local path with a
> changelist name
>
> - a new commandline option to specify a changelist name.
>
>
> Here's an imaginary demo of what this feature might be like.
>
>
> ---------------------------------
>
> $ cd wc
>
> $ echo "new text" >> foo.c
>
> $ touch bar.c; svn add bar.c
> A bar.c
>
> $ svn st
> M foo.c
> A bar.c
>
> $ svn changelist issue-2899 foo.c bar.c
> foo.c is is now part of changelist 'issue-2899'.
> bar.c is is now part of changelist 'issue-2899'.
>
> $ svn st
> Changelist 'issue-2899':
> M foo.c
> A bar.c
>
> $ echo "blah" >> baz.c
>
> $ svn st
> M baz.c
>
> Changelist 'issue-2899':
> M foo.c
> A bar.c
>
> $ svn changelist feature-baz baz.c
> baz.c is is now part of changelist 'issue-2899'.
>
> $ svn st
> Changelist 'feature-baz':
> M baz.c
>
> Changelist 'issue-2899':
> M foo.c
> A bar.c
>
> $ svn diff --changelist issue-2899
> (diffs for foo.c and bar.c are shown)
>
> $ svn rm glorb.h
> D glorb.h
>
> $ svn changelist feature-baz glorb.c
> svn: error: glorb.c isn't edited or scheduled.
>
> $ svn changelist feature-baz glorb.h
> glorb.h is is now part of changelist 'feature-baz'.
>
> $ svn st
> Changelist 'feature-baz':
> M baz.c
> D glorb.h
>
> Changelist 'issue-2899':
> 4 M foo.c
> A bar.c
>
> $ svn changelist issue-2899 glorb.h
> glorb.h is is now part of changelist 'issue-2899'.
>
> $ svn st
> Changelist 'feature-baz':
> M baz.c
>
> Changelist 'issue-2899':
> M foo.c
> A bar.c
> D glorb.h
>
> $ svn commit --changelist issue-2899
> Adding bar.c
> Sending foo.c
> Deleting glorb.h
> Transmitting file data..
> Committed revision 23489.
>
> -------------------------------
>
> How this is different than perforce:
>
>
> In perforce, the server tracks *every* working copy. In fact, working
> copy files are read-only, and you need to tell the server you want to
> edit them before they become read-write. Ergo, changelists are
> entirely tracked by the server. On the one hand, this makes commands
> like 'status' or 'commit' super-quick: instead of needing to crawl the
> working copy for changes, a quick network request to the server
> returns all the changed paths. On the other hand, this sort of thing
> is only possible with a system designed for a LAN. Subversion is
> WAN-based, so I'd never advocate that sort of design.
>
> An initial super-simple implementation of such a feature could be
> nothing more than attaching a changelist name as an 'entry-prop' in
> .svn/entries, or something similar. Later on, if we wanted to get
> fancy and try to make the svn client also be "super quick" and avoid
> crawls, we *could* have the client track changelists in a central
> registry, such as in ~/.subversion/. Of course, the tradeoff is that
> it takes us one more step towards the idea of working copies being
> non-divisible and non-portable. Not sure we want to open that
> discussion. :-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Tim Hill <ti...@realmgp.com>.
Jared Hardy wrote:
>
>
> When I was suggesting a "user-controlled branch commit now, merge to
> trunk later" workflow, I was just saying it is similar to your multi-WC
> workflow. Think (user-branch = WC-copy), just one is server-store and
> the other is local-store. The big difference is that
> branch-commit/trunk-merge cycles would benefit from pervasive
> changelists in a way that the multi-WC workflow would not. Users could
> re-use the same changelists (as used in previous branch commits) during
> the trunk-merge cycle. A multi-WC merge cycle is implicit in the WC
> commit order, and wouldn't have a lot of Changelist cross-over potential.
>
> --Jared
>
Understood. In other systems I've this called "shelving", where you can
push-out a set of changes to a temporary (private) space without a
commit, do some other work, and then un-shelf with (as necessary) a
private merge to get things back in sync. I think that's the same as
your branch-commit where the branch == the shelf.
My real push-back to Ben was really to question what the cost/benefit of
the proposal was if he is basing this on my (a) scenario, since that
seems to be primarily about svn assisting in book-keeping.
--Tim
Re: proposal: changelist feature
Posted by Jared Hardy <jh...@highimpactgames.com>.
Tim Hill wrote:
> Ben, I've been thinking more about this and while I'm just a peon (no
> voting and as yet no code contrib...), I do have a couple of issues with
> this proposal:
>
> First, what is the intention/scenario here? It seems to me we have two
> possibilities: (a) changelists as a mnemonic device, to assist in
> remembering what needs to be checked-in, and (b) changelists as an
> enforcement device, to add some kind of policy mechanism to help users
> in "doing the right thing".
>
> I assert that (a) can be handled comfortably with shell scripts, or (at
> most), the addition of a switch to the SVN client to read file list
> files (aka response files), i.e.:
>
> svn commit @changelist.txt -m "Commit log message"
>
> Where "changelist.txt" presumably contains a file list, delimited in
> some convenient manner.
> [snip]
I would say my description matches (a), but Ben's description does not
match (a) entirely. Implementing a changelist as a per-file Working Copy
(WC) property opens up the possibility of tracking major file changes
locally after the point the changelist property is applied. I.e. "svn mv
file" and "svn rename file" would not affect the changelist status of
the file. My description, and (a), where a list is maintained completely
outside the Working Copy (WC) system, makes tracking across moves and
renames non-trivial, and leaves more changelist updating tasks to the
user. Of course, (a) makes other features easier, such as including
items in a changelist that haven't even been modified/added yet, and
maintaining the same changelists across commits and WCs.
About (b), I would say user control of that form is a losing game.
Changelists should be about making it easier for users to commit, not
harder. Your multi-WC system sounds like a better way of going around
the "different patches intended, same file committed" problem mentioned
earlier.
When I was suggesting a "user-controlled branch commit now, merge to
trunk later" workflow, I was just saying it is similar to your multi-WC
workflow. Think (user-branch = WC-copy), just one is server-store and
the other is local-store. The big difference is that
branch-commit/trunk-merge cycles would benefit from pervasive
changelists in a way that the multi-WC workflow would not. Users could
re-use the same changelists (as used in previous branch commits) during
the trunk-merge cycle. A multi-WC merge cycle is implicit in the WC
commit order, and wouldn't have a lot of Changelist cross-over potential.
--Jared
> Ben Collins-Sussman wrote:
>
>> Hi folks, it's been a while since I worked on subversion coding
>> project. This is a proposal for a new client-side feature I'd like to
>> work on. (For svn 1.5, obviously, not 1.4).
>>
>> It's vaguely based on a similar feature in perforce, and it's
>> something a few of us have gotten used to since working at Google -- a
>> nice convenience.
>>
>> In a nutshell, it's a way to attach temporary names to groups of
>> edited files in a working copy. If you've ever been working on
>> several different patches or tasks at the same time, it's easy to get
>> them confused. Perforce allows you to give a name to a set of files,
>> called a 'changelist'.
>>
>> * 'svn status' would not only show local files as modified or
>> scheduled for addition/deletion, but also which changelist each
>> path belongs to. (Assuming you've bothered to assign changed
>> paths to changelists.)
>>
>> * Anytime one might normally use a list of local paths on the
>> commandline, one could use a changelist name instead. For
>> example, one could revert, diff, or commit a changelist name.
>>
>> * The only new UI-syntax we'd need is
>>
>> - the ability to associate (or deassociate) a local path with a
>> changelist name
>>
>> - a new commandline option to specify a changelist name.
>>
>>
>> Here's an imaginary demo of what this feature might be like.
>>
>>
>> ---------------------------------
>>
>> $ cd wc
>>
>> $ echo "new text" >> foo.c
>>
>> $ touch bar.c; svn add bar.c
>> A bar.c
>>
>> $ svn st
>> M foo.c
>> A bar.c
>>
>> $ svn changelist issue-2899 foo.c bar.c
>> foo.c is is now part of changelist 'issue-2899'.
>> bar.c is is now part of changelist 'issue-2899'.
>>
>> $ svn st
>> Changelist 'issue-2899':
>> M foo.c
>> A bar.c
>>
>> $ echo "blah" >> baz.c
>>
>> $ svn st
>> M baz.c
>>
>> Changelist 'issue-2899':
>> M foo.c
>> A bar.c
>>
>> $ svn changelist feature-baz baz.c
>> baz.c is is now part of changelist 'issue-2899'.
>>
>> $ svn st
>> Changelist 'feature-baz':
>> M baz.c
>>
>> Changelist 'issue-2899':
>> M foo.c
>> A bar.c
>>
>> $ svn diff --changelist issue-2899
>> (diffs for foo.c and bar.c are shown)
>>
>> $ svn rm glorb.h
>> D glorb.h
>>
>> $ svn changelist feature-baz glorb.c
>> svn: error: glorb.c isn't edited or scheduled.
>>
>> $ svn changelist feature-baz glorb.h
>> glorb.h is is now part of changelist 'feature-baz'.
>>
>> $ svn st
>> Changelist 'feature-baz':
>> M baz.c
>> D glorb.h
>>
>> Changelist 'issue-2899':
>> 4 M foo.c
>> A bar.c
>>
>> $ svn changelist issue-2899 glorb.h
>> glorb.h is is now part of changelist 'issue-2899'.
>>
>> $ svn st
>> Changelist 'feature-baz':
>> M baz.c
>>
>> Changelist 'issue-2899':
>> M foo.c
>> A bar.c
>> D glorb.h
>>
>> $ svn commit --changelist issue-2899
>> Adding bar.c
>> Sending foo.c
>> Deleting glorb.h
>> Transmitting file data..
>> Committed revision 23489.
>>
>> -------------------------------
>>
>> How this is different than perforce:
>>
>>
>> In perforce, the server tracks *every* working copy. In fact, working
>> copy files are read-only, and you need to tell the server you want to
>> edit them before they become read-write. Ergo, changelists are
>> entirely tracked by the server. On the one hand, this makes commands
>> like 'status' or 'commit' super-quick: instead of needing to crawl the
>> working copy for changes, a quick network request to the server
>> returns all the changed paths. On the other hand, this sort of thing
>> is only possible with a system designed for a LAN. Subversion is
>> WAN-based, so I'd never advocate that sort of design.
>>
>> An initial super-simple implementation of such a feature could be
>> nothing more than attaching a changelist name as an 'entry-prop' in
>> .svn/entries, or something similar. Later on, if we wanted to get
>> fancy and try to make the svn client also be "super quick" and avoid
>> crawls, we *could* have the client track changelists in a central
>> registry, such as in ~/.subversion/. Of course, the tradeoff is that
>> it takes us one more step towards the idea of working copies being
>> non-divisible and non-portable. Not sure we want to open that
>> discussion. :-)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: dev-help@subversion.tigris.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Tim Hill <ti...@realmgp.com>.
Ben, I've been thinking more about this and while I'm just a peon (no
voting and as yet no code contrib...), I do have a couple of issues with
this proposal:
First, what is the intention/scenario here? It seems to me we have two
possibilities: (a) changelists as a mnemonic device, to assist in
remembering what needs to be checked-in, and (b) changelists as an
enforcement device, to add some kind of policy mechanism to help users
in "doing the right thing".
I assert that (a) can be handled comfortably with shell scripts, or (at
most), the addition of a switch to the SVN client to read file list
files (aka response files), i.e.:
svn commit @changelist.txt -m "Commit log message"
Where "changelist.txt" presumably contains a file list, delimited in
some convenient manner.
If the intent is (b), I'm not clear what the goal is? For example, is
the intent to ensure that commit are atomic with regard to source tree
coherency? If that's the case, we would need behaviors that include
things like (a) disallowing checkins of individual files if they are on
a changelist and (b) disallowing a file on more than one changelist
(auto-merge). At that point a changelist is sounding more like a
work-item and is more related to overall development workflow?
Now, I think (b) might have value, but my reading of your proposal is
that this is not what you intended. Comments?
--Tim
Ben Collins-Sussman wrote:
> Hi folks, it's been a while since I worked on subversion coding
> project. This is a proposal for a new client-side feature I'd like to
> work on. (For svn 1.5, obviously, not 1.4).
>
> It's vaguely based on a similar feature in perforce, and it's
> something a few of us have gotten used to since working at Google -- a
> nice convenience.
>
> In a nutshell, it's a way to attach temporary names to groups of
> edited files in a working copy. If you've ever been working on
> several different patches or tasks at the same time, it's easy to get
> them confused. Perforce allows you to give a name to a set of files,
> called a 'changelist'.
>
> * 'svn status' would not only show local files as modified or
> scheduled for addition/deletion, but also which changelist each
> path belongs to. (Assuming you've bothered to assign changed
> paths to changelists.)
>
> * Anytime one might normally use a list of local paths on the
> commandline, one could use a changelist name instead. For
> example, one could revert, diff, or commit a changelist name.
>
> * The only new UI-syntax we'd need is
>
> - the ability to associate (or deassociate) a local path with a
> changelist name
>
> - a new commandline option to specify a changelist name.
>
>
> Here's an imaginary demo of what this feature might be like.
>
>
> ---------------------------------
>
> $ cd wc
>
> $ echo "new text" >> foo.c
>
> $ touch bar.c; svn add bar.c
> A bar.c
>
> $ svn st
> M foo.c
> A bar.c
>
> $ svn changelist issue-2899 foo.c bar.c
> foo.c is is now part of changelist 'issue-2899'.
> bar.c is is now part of changelist 'issue-2899'.
>
> $ svn st
> Changelist 'issue-2899':
> M foo.c
> A bar.c
>
> $ echo "blah" >> baz.c
>
> $ svn st
> M baz.c
>
> Changelist 'issue-2899':
> M foo.c
> A bar.c
>
> $ svn changelist feature-baz baz.c
> baz.c is is now part of changelist 'issue-2899'.
>
> $ svn st
> Changelist 'feature-baz':
> M baz.c
>
> Changelist 'issue-2899':
> M foo.c
> A bar.c
>
> $ svn diff --changelist issue-2899
> (diffs for foo.c and bar.c are shown)
>
> $ svn rm glorb.h
> D glorb.h
>
> $ svn changelist feature-baz glorb.c
> svn: error: glorb.c isn't edited or scheduled.
>
> $ svn changelist feature-baz glorb.h
> glorb.h is is now part of changelist 'feature-baz'.
>
> $ svn st
> Changelist 'feature-baz':
> M baz.c
> D glorb.h
>
> Changelist 'issue-2899':
> 4 M foo.c
> A bar.c
>
> $ svn changelist issue-2899 glorb.h
> glorb.h is is now part of changelist 'issue-2899'.
>
> $ svn st
> Changelist 'feature-baz':
> M baz.c
>
> Changelist 'issue-2899':
> M foo.c
> A bar.c
> D glorb.h
>
> $ svn commit --changelist issue-2899
> Adding bar.c
> Sending foo.c
> Deleting glorb.h
> Transmitting file data..
> Committed revision 23489.
>
> -------------------------------
>
> How this is different than perforce:
>
>
> In perforce, the server tracks *every* working copy. In fact, working
> copy files are read-only, and you need to tell the server you want to
> edit them before they become read-write. Ergo, changelists are
> entirely tracked by the server. On the one hand, this makes commands
> like 'status' or 'commit' super-quick: instead of needing to crawl the
> working copy for changes, a quick network request to the server
> returns all the changed paths. On the other hand, this sort of thing
> is only possible with a system designed for a LAN. Subversion is
> WAN-based, so I'd never advocate that sort of design.
>
> An initial super-simple implementation of such a feature could be
> nothing more than attaching a changelist name as an 'entry-prop' in
> .svn/entries, or something similar. Later on, if we wanted to get
> fancy and try to make the svn client also be "super quick" and avoid
> crawls, we *could* have the client track changelists in a central
> registry, such as in ~/.subversion/. Of course, the tradeoff is that
> it takes us one more step towards the idea of working copies being
> non-divisible and non-portable. Not sure we want to open that
> discussion. :-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by mark benedetto king <mb...@lowlatency.com>.
On Fri, Apr 21, 2006 at 07:56:41AM +0200, Peter N. Lundblad wrote:
> Peter Samuelson writes:
> >
> > [Jonathan Gilbert]
> > > Perhaps an extra switch could be used to put the changelist names
> > > first instead of last. As long as the list of changelists can itself
> > > be enumerated
> >
> > That's a big "if". As I understand it, enumerating the changelists
> > will make the operation just as unstreamy as sorting by changelist.
>
> Since all the entries are loaded while opening the working copy access baton,
> which is done recursively, assuming the changelist nmae is stored in the
> entryies file, enumerating the changelists would just be an in-memory
> traversal over the tree.
>
And maintaining a hash of what changesets have been encountered so far,
to prevent double-printing.
They're both unstreamy if you define streamy as "requiring bounded
space". In practice, however, there will be far fewer changesets than
files; streaminess in change-set enumeration is far less important that
streaminess in file-listing operations.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
Justin Erenkrantz writes:
> On 4/20/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> > Since all the entries are loaded while opening the working copy access baton,
> > which is done recursively, assuming the changelist nmae is stored in the
> > entryies file, enumerating the changelists would just be an in-memory
> > traversal over the tree.
>
> Do you mean that if we are in a large WC that we open and parse all
> descendent WCs dirs into memory and then perform ops on them?
>
That's how it works, yes. When opening a WC recursively, itis traversed
and to be able to open the children of a directory, the entries file
must be read. I don't know if it could be done lazily when we're not
locking the WC.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/20/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> Since all the entries are loaded while opening the working copy access baton,
> which is done recursively, assuming the changelist nmae is stored in the
> entryies file, enumerating the changelists would just be an in-memory
> traversal over the tree.
Do you mean that if we are in a large WC that we open and parse all
descendent WCs dirs into memory and then perform ops on them?
That's not what I would have expected... -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
Peter Samuelson writes:
>
> [Jonathan Gilbert]
> > Perhaps an extra switch could be used to put the changelist names
> > first instead of last. As long as the list of changelists can itself
> > be enumerated
>
> That's a big "if". As I understand it, enumerating the changelists
> will make the operation just as unstreamy as sorting by changelist.
Since all the entries are loaded while opening the working copy access baton,
which is done recursively, assuming the changelist nmae is stored in the
entryies file, enumerating the changelists would just be an in-memory
traversal over the tree.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Peter Samuelson <pe...@p12n.org>.
[Jonathan Gilbert]
> Perhaps an extra switch could be used to put the changelist names
> first instead of last. As long as the list of changelists can itself
> be enumerated
That's a big "if". As I understand it, enumerating the changelists
will make the operation just as unstreamy as sorting by changelist.
Re: proposal: changelist feature
Posted by Jonathan Gilbert <o2...@sneakemail.com>.
At 02:27 PM 17/04/2006 -0500, Ben Collins-Sussman wrote:
>On 4/17/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>> On 4/17/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
>> > I basically agree with what Justin said, although I'm not too fond of
>> > putting stuff in parens after the filename like that, I do think it
>>
>> Oh, I agree. I just don't know quite how to better represent it given
>> the constraints on status's output though. -- justin
>>
>
>Heh, that's in fact what perforce does: something like
>
> /some/long/path/to/foo.c - modified XXXX
> /some/other/path/to/bar.c - added XXXX
>
>...where XXXX is the changelist name.
>
>Of course, I absolutely hate this output, because there are no aligned
>columns at all. It's really hard to read. That's why 'svn status'
>shows neatly aligned status codes, and puts the variable-length path
>last.
>
>Unfortunately, adding a changelist-name to the output of 'svn status'
>would mean each line would now have *two* variable-length fields. And
>I guess you guys are right -- it's not worth destroying the
>streaminess of the status command just to show changelist groupings.
>I guess Justin's suggestion is the best we could do.
Perhaps an extra switch could be used to put the changelist names first
instead of last. As long as the list of changelists can itself be
enumerated, it shouldn't be hard to correctly size this new first column,
and the resulting output could be passed to 'sort' for those interested in
grouping by changelist. Of course, the default output should be to put the
changelist last or perhaps even not show it at all. (An alias could be used
to add a --show-changelists flag, without which third-party tools which
wrap the 'svn' utility would only see the changelist output if they knew
about it and were able to handle it.)
Example:
box:/wc> svn st
A foo.c
D bar.c
M qux.c
box:/wc> svn st --show-changelists
A foo.c (changelist "abc123")
D bar.c (changelist "bongo drums")
M qux.c (changelist "abc123")
box:/wc> svn st --show-changelists=sortable
abc123 A foo.c
bongo drums D bar.c
abc123 M qux.c
box:/wc> svn st --show-changelists=sortable | sort
abc123 A foo.c
abc123 M qux.c
bongo drums D bar.c
box:/wc>
Jonathan Gilbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 4/20/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> Ben Collins-Sussman writes:
> > Here's my plea: let me make a feature branch, and code this really
> > simple bookkeeping feature. Once you've all played with it and
> > discovered how (unexpectedly) useful it is, we can go back and visit
> > some of these other more complex feature proposals in new mail
> > threads...
>
> Well, what I *think* I'd really want would be some kind of patch manager:
> - Hey, store away my patch in progress so I can do this little bugfix.
> - Now, reapply my patch (including tree changes), so I can continue on my
> new killer feature.
>
> This is clearly a bigger task and maybe it doesn't even belong in the
> SCM itslef, so I think your proposal is a step in the right direction,
> so +1.
I agree... the feature you propose above will be made easier if my
simple bookkeeping feature existed first. :-)
(By the way, your feature could also be solved if svn started using a
custom patch format, which a few of us have played with already.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
Ben Collins-Sussman writes:
> Here's my plea: let me make a feature branch, and code this really
> simple bookkeeping feature. Once you've all played with it and
> discovered how (unexpectedly) useful it is, we can go back and visit
> some of these other more complex feature proposals in new mail
> threads...
Well, what I *think* I'd really want would be some kind of patch manager:
- Hey, store away my patch in progress so I can do this little bugfix.
- Now, reapply my patch (including tree changes), so I can continue on my
new killer feature.
This is clearly a bigger task and maybe it doesn't even belong in the
SCM itslef, so I think your proposal is a step in the right direction,
so +1.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Jared Hardy <jh...@highimpactgames.com>.
> On 4/20/06, Julian Foad <ju...@btopenworld.com> wrote:
>>Let's make 'svn status' accept the '--targets FILELISTFILE' option
anyway. I
>>think all commands that accept an arbitrary number of targets should
accept it.
Hyrum K. Wright wrote:
> I also agree that 'svn status' should accept the '--targets' option.
> Attached is a patch to that effect. I'll look for other cases where
> commands which take an arbitrary number of targets and are not yet
> accepting the '--targets' option.
I agree! I didn't even notice this option before, I guess because it
didn't appear as an option in the help for "svn update", which is the
most often used command around my office. Is "svn update" or "svn merge"
accepting "--targets" yet? The "svn help" text for them doesn't show it,
as of 1.3.0. That would definitely help with my GUI tool plans. I could
almost just use the GUI tool to generate/track target files, with
associated comment files, and have a background script do the rest. :)
Thanks!
Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Michael Brouwer <mb...@gmail.com>.
On 4/21/06, Jared Hardy <jh...@highimpactgames.com> wrote:
> Marc Sherman wrote:
> > Another idea might be to add a --create-targets switch to svn st; this
> > would change the output to a simple file list, suitable for redirecting
> > to a targets file for later use with the --targets switch. That seems
> > to cover all of Ben's use cases for changelists, I think.
>
> This sounds useful. I would add that some options to filter on status
> would make it *extremely* useful. For example:
>
> svn st /path/ --create-targets "~!" > filename
svn st /path/ | grep '^~!' | sed 's/...... //' > filename
Does this already today, and the other examples you gave can be
scriped in a similar way.
Michael
Re: proposal: changelist feature
Posted by Jared Hardy <jh...@highimpactgames.com>.
Marc Sherman wrote:
> Another idea might be to add a --create-targets switch to svn st; this
> would change the output to a simple file list, suitable for redirecting
> to a targets file for later use with the --targets switch. That seems
> to cover all of Ben's use cases for changelists, I think.
This sounds useful. I would add that some options to filter on status
would make it *extremely* useful. For example:
svn st /path/ --create-targets "~!" > filename
Would output a list of all the versioned-obstructed and missing files
under /path/, dumped into to filename. Another example:
svn st /path/ -u --create-targets "M*" > filename
Would output a list of all the modified files for which a newer version
exists on the server.
These characters are taken from the "svn help status" list, making for
nice UI consistency.
In my experience, "svn log /path/ -v -r HEAD:BASE" and similar commands
are also much faster than "svn status ..." commands, because they don't
require the same dirtree-walk slowness, esp on NTFS with a LAN
connection to the server. A "svn log /path/ -v -r HEAD:BASE
--create-targets 'DAM'" command could potentially be more useful for
generating "svn update --targets" files. Just imagine this batch (pardon
the weak DOS batch -- how I long for a proper shell):
svn log %1 -v -r HEAD:BASE --create-targets 'AM' > newlist.txt
svn status --create-targets '?~' --targets newlist.txt > unversioned.txt
FOR /F %%i IN (unversioned.txt) DO (
move /y %%i %%i.~bak~
)
svn update --targets newlist.txt
FOR /F %%i IN (unversioned.txt) DO (
move /y %%i.~bak~ %%i
)
That would be a nice work-around to the "unversioned file exists" error
we get when Updating build target directories. Even just having "svn log
%1 -v -r HEAD:BASE --create-targets 'DAM' | svn update" would speed up
Updates for all our local users significantly.
Thanks!
Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Marc Sherman <ms...@projectile.ca>.
Hyrum K. Wright wrote:
>
> I also agree that 'svn status' should accept the '--targets' option.
> Attached is a patch to that effect. I'll look for other cases where
> commands which take an arbitrary number of targets and are not yet
> accepting the '--targets' option.
Another idea might be to add a --create-targets switch to svn st; this
would change the output to a simple file list, suitable for redirecting
to a targets file for later use with the --targets switch. That seems
to cover all of Ben's use cases for changelists, I think.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On 4/20/06, Julian Foad <ju...@btopenworld.com> wrote:
> Let's make 'svn status' accept the '--targets FILELISTFILE' option anyway. I
> think all commands that accept an arbitrary number of targets should accept it.
I also agree that 'svn status' should accept the '--targets' option.
Attached is a patch to that effect. I'll look for other cases where
commands which take an arbitrary number of targets and are not yet
accepting the '--targets' option.
[[[
Make 'svn status' accept and use the '--targets' option.
* subversion/svn/main.c:
(svn_cl__cmd_table): Add svn_cl__targets_opt to the list of options
accepted by 'svn status'.
]]]
Re: proposal: changelist feature
Posted by Julian Foad <ju...@btopenworld.com>.
Ben Collins-Sussman wrote:
> On 4/20/06, Julian Foad <ju...@btopenworld.com> wrote:
>
>>We certainly
>>don't want to promote the idea that a "change" in Subversion can be represented
>>as a list of files.
>
> We don't? How do you explain the list of paths at the top of each log
> message in 'svn log -v'?
A list of paths involved in a change is meta-data about the change. In limited
circumstances (such as during a commit, or when changes affect disjoint sets of
paths) it is sufficient to identify the change. I'm not saying that such a
list isn't useful, just that we don't want to accidentally give the impression,
in describing this feature, that it represents our idea of "change management",
because it would fall short of what that implies.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 4/20/06, Julian Foad <ju...@btopenworld.com> wrote:
> We certainly
> don't want to promote the idea that a "change" in Subversion can be represented
> as a list of files.
We don't? How do you explain the list of paths at the top of each log
message in 'svn log -v'?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Julian Foad <ju...@btopenworld.com>.
Ben Collins-Sussman wrote:
> Here's my plea: let me make a feature branch, and code this really
> simple bookkeeping feature. Once you've all played with it and
> discovered how (unexpectedly) useful it is, we can go back and visit
> some of these other more complex feature proposals in new mail
> threads...
I have no problem with you making a branch on which to try out your ideas, as
long as you and we realise that doing so does not increase the likelihood of us
accepting those ideas.
As you develop it, also write the documentation and/or specification. (They
should be more or less the same as each other.) If thoroughly written, this
will show up clearly how well the idea fits in with Subversion's existing concepts.
I think you will find that what you are implementing is a "file list" rather
than a "change list". "File list" functionality is already partly handled by
the "--targets" option and perhaps just needs extending somewhat. We certainly
don't want to promote the idea that a "change" in Subversion can be represented
as a list of files.
> [...] (Yes, it could be done by users keeping changelists in a bunch
> of text-files, but it wouldn't be as convenient, and 'svn status'
> wouldn't be able to show them, which is the critical bit for me.)
Let's make 'svn status' accept the '--targets FILELISTFILE' option anyway. I
think all commands that accept an arbitrary number of targets should accept it.
Then see whether it really wouldn't be as convenient. If you're happy to use
'svn status --targets CHANGELIST' as the way to show files belonging to a
certain list, I think your feature requires only the addition of something like:
svn changelist CHANGELIST FILE...
(basically 'echo FILE... >> CHANGELIST')
I feel the management of such file-list files should not be a first-class
operation in Subversion and would better be handled by external utilities.
May I urge you to try out an implementation based on such file-list files, and
see how well it works.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 4/24/06, Michael Sinz <Mi...@sinz.org> wrote:
> A much better option would be if "svn diff" had an option to make a
> full, subversion feature complete, diff file (maybe nothing like diff or
> maybe exactly like diff) that could then be saved somewhere by the
> user. Then, there would need to be some "svn apply diff.file" that
> would apply the diff back into the repository.
Here it is:
http://svn.red-bean.com/repos/sussman/software/subversion/svnpatch/trunk/
When svn first started, before the repository existed, 'svn commit'
produced an XML file, and 'svn update' read the same XML back. Erik
and I have resurrected that code, and have been playing around with it
in the project above. Not yet fully resurrected, but it produces the
XML patchfile.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Michael Sinz <Mi...@sinz.org>.
On 4/21/06, Tim Hill <ti...@realmgp.com> wrote:
>
> Ben Collins-Sussman wrote:
> > It's interesting where this thread has gone! I originally proposed a
> > tiny bookkeeping feature, based on the fact that I (and others) have
> > become addicted to said bookkeeping when using perforce every day. I
> > was initially worried that the discussion would start heading down a
> > path of "stop crawling the working copy, store changelists in
> > ~/.subversion/", which is a very perforce-like thing to do.
> >
> Indeed! Incidentally, I wasn't voting *for* any SCM methodology, I just
> wondered if that's where this was going.
>
> WRT the "shelf" idea, why shouldn't this just be an SVN command that can
> automatically "trim" a WC down to the minimum number of files or folders
> that hold all changes made to date? This should be possible just by
> looking at WC data (local operation), and after operation the trimmed WC
> *is* the shelf. Then, all the user needs to do is checkout a new WC for
> the next set of changes. To unshelf, all that's needed is to re-sync the
> shelved WC from the repo. This sounds a lot cheaper than "local
> checkins", both to implement and from the feature-bloat perspective.
>
> Does this make sense? If so I might expand this as a feature proposal
> and/or look at the code overhead to implement?
Well, while that would work, I would hate the network overhead on larger
projects (can anyone say GCC ?)
I have 12 files that were changed in some way and now you trim away
thousands of files to make the shelf? Pulling them back is "easy" other
than the network overhead.
A much better option would be if "svn diff" had an option to make a
full, subversion feature complete, diff file (maybe nothing like diff or
maybe exactly like diff) that could then be saved somewhere by the
user. Then, there would need to be some "svn apply diff.file" that
would apply the diff back into the repository. Think of it sort of like
a way to make a file that is what is needed to do a svn merge operation
with the only difference being that the diff/merge is based on the
differences within the WC and not two revisions in the repository.
Actually, in one thing I work on that would be generally useful if
the "svn diff" command with this extra option could work beyond just
the WC and with revisions in the repository. It would allow the packaging
of a change set/merge operation. (Basically, like diff/patch only with
properties and rename/move/copy operations enumerated correctly)
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:Michael.Sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Tim Hill <ti...@realmgp.com>.
Ben Collins-Sussman wrote:
> It's interesting where this thread has gone! I originally proposed a
> tiny bookkeeping feature, based on the fact that I (and others) have
> become addicted to said bookkeeping when using perforce every day. I
> was initially worried that the discussion would start heading down a
> path of "stop crawling the working copy, store changelists in
> ~/.subversion/", which is a very perforce-like thing to do.
>
Indeed! Incidentally, I wasn't voting *for* any SCM methodology, I just
wondered if that's where this was going.
WRT the "shelf" idea, why shouldn't this just be an SVN command that can
automatically "trim" a WC down to the minimum number of files or folders
that hold all changes made to date? This should be possible just by
looking at WC data (local operation), and after operation the trimmed WC
*is* the shelf. Then, all the user needs to do is checkout a new WC for
the next set of changes. To unshelf, all that's needed is to re-sync the
shelved WC from the repo. This sounds a lot cheaper than "local
checkins", both to implement and from the feature-bloat perspective.
Does this make sense? If so I might expand this as a feature proposal
and/or look at the code overhead to implement?
--Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Ben Collins-Sussman <su...@red-bean.com>.
It's interesting where this thread has gone! I originally proposed a
tiny bookkeeping feature, based on the fact that I (and others) have
become addicted to said bookkeeping when using perforce every day. I
was initially worried that the discussion would start heading down a
path of "stop crawling the working copy, store changelists in
~/.subversion/", which is a very perforce-like thing to do.
Instead, however, people have been wandering down two other paths I'd
didn't anticipate.
* Some folks have started with my idea, and inferred some sort of a
structured SCM methodology being imposed on users. This was never my
intent. Changelists aren't things to be "enforced" by the software...
I really only meant them to be some convenient bookkeeping on the
side. (Yes, it could be done by users keeping changelists in a bunch
of text-files, but it wouldn't be as convenient, and 'svn status'
wouldn't be able to show them, which is the critical bit for me.)
* Other folks have brought up the idea (in this thread, and in IRC)
of "well, heck, what people _really_ want are enhanced commit
abilities". Some have suggested a 'shelving' feature, which allows
one to push a patch-in-progress to an automatically-generated
mini-branch in the repository. A few others have suggested "offline
commits", as seen in distributed SCMs, whereby the working copy
becomes "deeper", able to hold more than one tree at a time.
I definitely have no interest in the first bullet. I feel like the
ideas in the second bullet are interesting, but also a bit out of
scope for my ambitions at the moment. If anything, while my proposal
might 'inspire' those ideas, I feel like they're orthogonal projects.
Here's my plea: let me make a feature branch, and code this really
simple bookkeeping feature. Once you've all played with it and
discovered how (unexpectedly) useful it is, we can go back and visit
some of these other more complex feature proposals in new mail
threads...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
> On Mon, Apr 17, 2006 at 02:27:41PM -0500, Ben Collins-Sussman wrote:
>
>> ...
>> Unfortunately, adding a changelist-name to the output of 'svn status'
>> would mean each line would now have *two* variable-length fields. And
>> I guess you guys are right -- it's not worth destroying the
>> streaminess of the status command just to show changelist groupings.
>> I guess Justin's suggestion is the best we could do.
>>
>
> Euh... that format breaks the machine-parsability of the lines. How do
> you know the file isn't named "foo.c (changelist 'borken')" ?? Answer
> is: you don't.
>
> I don't have any suggestions, but did want to call that out.
>
Even grouping status output by changelist would break parseability. I
suppose that people who feed the output into other programs and need
100% correct parsing are stuck with --xml anyway...
I do like the grouped status output better, though, because it's more
readable for /humans/. A "svn st --changelist" would also be useful -- i
expect it's an obvious feature, though.
-- Brane
Re: proposal: changelist feature
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Apr 17, 2006 at 02:27:41PM -0500, Ben Collins-Sussman wrote:
>...
> Unfortunately, adding a changelist-name to the output of 'svn status'
> would mean each line would now have *two* variable-length fields. And
> I guess you guys are right -- it's not worth destroying the
> streaminess of the status command just to show changelist groupings.
> I guess Justin's suggestion is the best we could do.
Euh... that format breaks the machine-parsability of the lines. How do
you know the file isn't named "foo.c (changelist 'borken')" ?? Answer
is: you don't.
I don't have any suggestions, but did want to call that out.
Cheers,
-g
--
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: proposal: changelist feature
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 4/17/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On 4/17/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > I basically agree with what Justin said, although I'm not too fond of
> > putting stuff in parens after the filename like that, I do think it
>
> Oh, I agree. I just don't know quite how to better represent it given
> the constraints on status's output though. -- justin
>
Heh, that's in fact what perforce does: something like
/some/long/path/to/foo.c - modified XXXX
/some/other/path/to/bar.c - added XXXX
...where XXXX is the changelist name.
Of course, I absolutely hate this output, because there are no aligned
columns at all. It's really hard to read. That's why 'svn status'
shows neatly aligned status codes, and puts the variable-length path
last.
Unfortunately, adding a changelist-name to the output of 'svn status'
would mean each line would now have *two* variable-length fields. And
I guess you guys are right -- it's not worth destroying the
streaminess of the status command just to show changelist groupings.
I guess Justin's suggestion is the best we could do.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/17/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> I basically agree with what Justin said, although I'm not too fond of
> putting stuff in parens after the filename like that, I do think it
Oh, I agree. I just don't know quite how to better represent it given
the constraints on status's output though. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/17/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On 4/17/06, Ben Collins-Sussman <su...@red-bean.com> wrote:
> > $ echo "blah" >> baz.c
> >
> > $ svn st
> > M baz.c
> >
> > Changelist 'issue-2899':
> > M foo.c
> > A bar.c
>
> My hunch is that it'd be far easier to have it be:
>
> $ svn st
> M baz.c
> M foo.c (Changelist 'issue-2899')
> A bar.c (Changelist 'issue-2899')
>
> There's no guarantees of ordering in the editors, so splitting out
> changelist items like we do with externals seems like it wouldn't be
> trivial. (You'd have to suppress them in the first pass and then only
> emit the per-changelist mods separately.)
>
> BTW, can a file be in more than one changelist at a time? If so, how
> would that work?
>
> The other UI changes look reasonable at first glance though. I look
> forward to your patches on this. ;-)
I basically agree with what Justin said, although I'm not too fond of
putting stuff in parens after the filename like that, I do think it
needs to be per-entry, not all displayed at the end like your initial
proposal.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Gareth McCaughan <ga...@pobox.com>.
> So yeah, we have a couple of big tensions here:
>
> * streamy output vs. displaying grouped-changelists:
...
> * not breaking existing parse-scripts too much
The operation that's difficult to provide nice
output for is the one that supplies changelist
information for multiple paths that might be in
multiple changelists. The key difficulty is that
the paths and the changelists are both variable-length.
So, how would it be to decouple so that the only
operation available that lists all changelists
did *only* that? In other words, you'd get
- svn list-changelists
(lists concisely what changelists there are;
perhaps actually svn status --list-changelists
or svn changelist --list)
- svn status
(same as at present; lists all changed paths)
- svn status --changelist <name>
(restricts to changes that are part of the given
changelist; perhaps multiple --changeset args
can be given, producing multiple lists but no
more efficiently than running svn status multiple
times with one --changeset each)
That way everything can stay streamy, and you don't
have multiple variable-length fields on a line, and
all the information you'd need is available, and
you don't need to deal with funky indirected output.
The downside, of course, is that you don't get the
ability to see all changed paths with their changelist
names; how much would that matter? Not too much, I'm
inclined to think, but I'm just guessing.
Remark: It should probably be possible to attach a
(typically short) description to a changelist; the
changelist-listing command should be able to provide
those descriptions as well as just the names.
$ svn changelist issue-1234 --description "Adding the algebraic
equation-solving feature." commands.c solve.c constants.h
commands.c is is now part of changelist 'issue-1234'.
solve.c is is now part of changelist 'issue-1234'.
constants.h is is now part of changelist 'issue-1234'.
# oops
$ svn changelist issue-1234 --remove constants.h
constants.h is no longer part of changelist 'issue-1234'.
[...]
$ svn changelist --list
issue-1234
issue-4321
gb-refactor
$ svn changelist --list --verbose
issue-1234
Adding the algebraic equation-solving feature.
issue-4321
Fixing jsmith's bug where we claim that 1=0.
gb-refactor
Diddling the data structures for the Groebner
basis calculations.
$ svn status --changelist issue-1234
M commands.c
A solve.c
$ svn status --changelist issue-1234 --changelist issue-4321
* Changelist 'issue-1234':
M commands.c
A solve.c
* Changelist 'issue-4321':
M constants.h
M equality.c
--
g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Thanks for the feedback, guys.
So yeah, we have a couple of big tensions here:
* streamy output vs. displaying grouped-changelists:
These are mutually exclusive goals. In the past, we've gone through
hell to make 'svn status' streamy, and benefits are huge: a massive
perception of speedup, and bounded memory use. I have to say, if
forced to choose, I think preserving the streamyness is more important
that displaying changelists as groups.
* not breaking existing parse-scripts too much
We've added columns to 'svn status' output in previous releases, so we
have precedent to add more things. But we'd like to do it in a way
that's as non-disruptive as possible. Adding a variable-length
changelist name after the path is pretty annoying, as epg pointed out.
I have to admit, I think I agree with Marc and Justin. Marc's
proposal allows us to to use a fixed-width column (which is very easy
on parsers), and also allows us to preserve streamyness.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by David Anderson <da...@calixo.net>.
* Eric Gillespie <ep...@pretzelnet.org> [2006-04-17 12:48:36]:
> I'm not sure what would be better. Maybe only display changelist
> information with an option to status?
I think this changeset feature would be interesting enough to be
enabled by default, especially if the output isn't altered if you
don't use the feature.
So that the output remains script-friendly, displaying changeset names
should be disableable, and svn stat should have an option like
--only-changeset <foo> to restrict output to a given changeset, but
with the current format (ie. no reprinting of the selected changeset
name).
I realize that this is a problem on the backward compatibility of
output front, but it is the best solution I can see for both users and
scripts going forward.
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/17/06, Marc Sherman <ms...@projectile.ca> wrote:
> Here's an option that's kind of ugly, but both streamy and fixed-width:
>
> ---
> $ svn st
> M baz.c
> M 1 foo.c
> A 1 bar.c
>
> Changelists:
> 1 issue-2899
> ---
>
> It does consume the last available empty column in the st output,
> though, which might cause objections.
That's about the only other format I can think of too without just
having changelists be ignored unless explicitly asked for. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Marc Sherman <ms...@projectile.ca>.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
>
>> My hunch is that it'd be far easier to have it be:
>>
>> $ svn st
>> M baz.c
>> M foo.c (Changelist 'issue-2899')
>> A bar.c (Changelist 'issue-2899')
Eric Gillespie wrote:
>
> -1 on this output format. How am i supposed to get the filename
> out of that? The current output format has a fixed number of
> fixed-width columns, and everything after that is the filename.
> All existing scripts that parse status end up with a bogus
> filename "foo.c (Changelist 'issue-2899')".
Here's an option that's kind of ugly, but both streamy and fixed-width:
---
$ svn st
M baz.c
M 1 foo.c
A 1 bar.c
Changelists:
1 issue-2899
---
It does consume the last available empty column in the st output,
though, which might cause objections.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> My hunch is that it'd be far easier to have it be:
>
> $ svn st
> M baz.c
> M foo.c (Changelist 'issue-2899')
> A bar.c (Changelist 'issue-2899')
-1 on this output format. How am i supposed to get the filename
out of that? The current output format has a fixed number of
fixed-width columns, and everything after that is the filename.
All existing scripts that parse status end up with a bogus
filename "foo.c (Changelist 'issue-2899')".
I'm not sure what would be better. Maybe only display changelist
information with an option to status?
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/17/06, Ben Collins-Sussman <su...@red-bean.com> wrote:
> $ echo "blah" >> baz.c
>
> $ svn st
> M baz.c
>
> Changelist 'issue-2899':
> M foo.c
> A bar.c
My hunch is that it'd be far easier to have it be:
$ svn st
M baz.c
M foo.c (Changelist 'issue-2899')
A bar.c (Changelist 'issue-2899')
There's no guarantees of ordering in the editors, so splitting out
changelist items like we do with externals seems like it wouldn't be
trivial. (You'd have to suppress them in the first pass and then only
emit the per-changelist mods separately.)
BTW, can a file be in more than one changelist at a time? If so, how
would that work?
The other UI changes look reasonable at first glance though. I look
forward to your patches on this. ;-) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/17/06, Jim Correia <ji...@pobox.com> wrote:
> It would be great if svn ci at the root of a WC gave me a similar,
> convenient way to do this. (I know I can do it today, in any number
> of ways, but none of them feels as convenient as it is in perforce.)
This feature has been proposed, and discussed ad-infinitum, several
times on this list. Please see the archives for details.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Jim Correia <ji...@pobox.com>.
On Apr 17, 2006, at 2:10 PM, Ben Collins-Sussman wrote:
> Hi folks, it's been a while since I worked on subversion coding
> project. This is a proposal for a new client-side feature I'd like to
> work on. (For svn 1.5, obviously, not 1.4).
>
> It's vaguely based on a similar feature in perforce, and it's
> something a few of us have gotten used to since working at Google -- a
> nice convenience.
If you are going to go down this road, might I suggest borrowing a
bit of intelligence from Perforce's submit form.
I use Perforce at work. To be honest, I almost never use changelists
for files in progress because I don't need to. When I'm ready to
submit something, I issue a p4 submit. Here is an example of the
submit form (this will look familiar to perforce users):
Change: new
Client: jims_client_spec
User: correia
Status: new
Description:
<enter description here>
Files:
//depot/MyFancyProject/main.c # edit
//depot/MyFancyProject/unit_tests.c # edit
The small, but great feature here, is that if any files in the Files
section aren't ready to submit, or aren't logically part of this
change, you just delete them from the Files section and they aren't
submitted.
It would be great if svn ci at the root of a WC gave me a similar,
convenient way to do this. (I know I can do it today, in any number
of ways, but none of them feels as convenient as it is in perforce.)
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/18/06, Marc Sherman <ms...@projectile.ca> wrote:
> Ben Collins-Sussman wrote:
> >
> >> If a file is a member of a changelist and it's committed, is it
> >> removed from the changelist?
> >>
> >
> > Yes. A very strange corner case, though, since presumably the whole
> > reason it was part of the changelist in the first place was so that it
> > could be committed as part of a larger change.
>
> It might be helpful to error out in that case, and require --force to
> continue.
It's not possible to detect that case with the current design for
changelists that Ben has put forth. If membership in a changelist is
controlled by a property of some sort on the file, you have no way to
determine that you've got all of the members of the list in a commit.
What if a file in another part of the working copy (a sibling of the
root dir you passed to 'commit') is in the changelist?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Marc Sherman <ms...@projectile.ca>.
Ben Collins-Sussman wrote:
>
>> If a file is a member of a changelist and it's committed, is it
>> removed from the changelist?
>>
>
> Yes. A very strange corner case, though, since presumably the whole
> reason it was part of the changelist in the first place was so that it
> could be committed as part of a larger change.
It might be helpful to error out in that case, and require --force to
continue.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 4/18/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> On 4/17/06, Ben Collins-Sussman <su...@red-bean.com> wrote:
>
> > An initial super-simple implementation of such a feature could be
> > nothing more than attaching a changelist name as an 'entry-prop' in
> > .svn/entries, or something similar. Later on, if we wanted to get
> > fancy and try to make the svn client also be "super quick" and avoid
> > crawls, we *could* have the client track changelists in a central
> > registry, such as in ~/.subversion/. Of course, the tradeoff is that
> > it takes us one more step towards the idea of working copies being
> > non-divisible and non-portable. Not sure we want to open that
> > discussion. :-)
>
> A few more ideas that occurred to me...
>
> Can files be added to a changelist if they haven't been modified?
I'd say 'no', and I put that in my demo. It keeps life simpler.
> What happens when a file has been added to a changelist, then is
> reverted?
It loses the changelist tag.
> If a file is a member of a changelist and it's committed, is it
> removed from the changelist?
>
Yes. A very strange corner case, though, since presumably the whole
reason it was part of the changelist in the first place was so that it
could be committed as part of a larger change.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/17/06, Ben Collins-Sussman <su...@red-bean.com> wrote:
> An initial super-simple implementation of such a feature could be
> nothing more than attaching a changelist name as an 'entry-prop' in
> .svn/entries, or something similar. Later on, if we wanted to get
> fancy and try to make the svn client also be "super quick" and avoid
> crawls, we *could* have the client track changelists in a central
> registry, such as in ~/.subversion/. Of course, the tradeoff is that
> it takes us one more step towards the idea of working copies being
> non-divisible and non-portable. Not sure we want to open that
> discussion. :-)
A few more ideas that occurred to me...
Can files be added to a changelist if they haven't been modified?
What happens when a file has been added to a changelist, then is
reverted? Does it revert both the changes and its membership in the
changelist or does changelist membership exist separately?
If a file is a member of a changelist and it's committed, is it
removed from the changelist?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: proposal: changelist feature
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
> Hi folks, it's been a while since I worked on subversion coding
> project. This is a proposal for a new client-side feature I'd like to
> work on. (For svn 1.5, obviously, not 1.4).
>
[etc.]
Now to throw a spanner in the works ... another thing that would be
useful for jugging several changes at once would be a local
checkpoint-and-rollback feature that would let you periodically store
changes locally (i.e., not commit to the server but to the working
copy), diff between these checkpoints and roll back changes. Without
branching, of course. At least for now. :)
-- Brane