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
>
>
Received on Wed Apr 19 03:22:43 2006