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
Received on Thu Apr 20 09:25:13 2006