-----BEGIN PGP SIGNED MESSAGE-----
On Sep 27, 2004, at 1:57 PM, Brad Appleton wrote:
> On Mon, Sep 27, 2004 at 01:05:14PM -0600, Tom Mornini wrote:
>> It would appear to me, who originally came to version control
>> via CVS, but now have experience with Subversion, and some of
>> the large commercial systems including ChangeMan DS, Perforce,
>> PVCS and Dimensions, that the VAST majority of people who want
>> CVS style labels have a few issues with copies:
> Just to clarify. Some people here aren't necessarily asking for
> CVS-style labels. (Some are, and some are not)
> For example, I think the request to allow an "alias" to be
> associated with a revo is very different from a CVS-style label
> (and it is a request which works within the existing hierarchical
> namespace of copies).
Yes, I agree 100% that it *might* be nice to have the ability to
associate BUILD_xyz with a specific revision number. However, I
do not believe for a moment that this capability, as useful as it
may be, will reduce people's wishes for tags.
A revision is the entire repository, after all. A tag (in CVS at
least) could be the entire repository, pieces and parts, or even
a single file.
For this reason, I believe that many users who want tags will be
disappointed with mnemonic for revision numbers.
*I Think* that what people find uncomfortable about copies is
that the ADDRESS or LOCATION changes. It's easier for people
to relate to the same ADDRESS or LOCATION, at a particular time,
or a particular subset, or even a particular branch.
>> 2) Lack of a direct way to see the result of copies when
>> issuing commands (log) against the original file! I think
>> this is an inarguably useful thing to expect from a version
>> control system.
> I must have missed that one. I don't know what it's asking for.
Well, 'cvs log' first lists which tags are associated with each
file. This information is NOT easier gatherable via Subversion.
>> 3) A basic misunderstanding that somehow, someway, regardless
>> of what everyone keeps telling them, copies at NOT cheap.
> Some would day that making a "copy" basically lets you
> "kill two birds with one stone". Each of those birds had
> its own useful purpose. Anytime the same mechanism lets you
> achieve two purposes - there is always going to be a question
> of cleanness of conceptual separation regarding the resulting
> usage for those cases where their (legitimate) usage doesn't
> cleanly map to the implementation.
Others would say that keeping the feature set minimalist, and
not cluttering it with useful, though technically arbitrary
'fixes' (which some may classify as crutches for some people's
inability or unwillingness to adopt to a new conceptual model)
may, over time, destroy both the technical and conceptual
cleanliness of an inherently more powerful model.
I believe what would, in fact, be most useful and most clean,
would be mnemonic name both ADDRESS and REVISION. This could
perhaps be very similar to svn:externals, with the inclusion
of revision number. svn:internal anyone?
>> Notice repeated usage in this thread of derogatory words
>> such as overkill, and suggestions that it is somehow
>> wasteful, or more than you want or need, to make copies.
> Yes. And I believe most of that has very little to do with
> how much time/space it requires to make copies. I think it
> has to do with perceived presence or absence of conceptual
> clutter and complexity and "cleanness". Some might describe
> it as an issue of closeness or "distance" between the
> "problem domain model" and the "solution domain representation".
> The conflict is of course that everyone's "mental model" of the
> problem domain in this case is a little different. Some are
> strongly biased by experience from one or more tools, some
> are more biased by what they believe are fundamental principles
> and concepts behind their own mental model of the "theory of
> operation" behind the concepts and their implementation.
I think you are 100% correct in this assesment.
- -- Tom Mornini
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Sep 27 22:45:00 2004