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
Received on Tue Apr 18 05:33:25 2006