[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: I miss tags

From: Brad Appleton <brad_at_bradapp.net>
Date: 2004-09-27 21:57:01 CEST

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).

> 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.

> 3) A basic misunderstanding that somehow, someway, regardless
> of what everyone keeps telling them, copies at NOT cheap.

I think that issue is not about whether or not copies are
"cheap" in terms of their storage or performance. I think
the issue is about different perceptions of what is
a "suitable" separation of concerns and "appropriate"
encapsulation of the representation (both conceptually
as well as in the UI).

When someone says "but I don't want it to appear in the copy-tree",
I don't believe their concern has much to do with processing
time or space required. Someone else may say "so then hide
it over here, and don't worry about the time/space because it's
cheap" and that doesn't address the concern being expressed;
it dismisses it rather than addresses it.

Each path-name and path-component in the hierarchical "copy"
namespace has conceptual meaning and significance associated
with it. People's reasons for not wanting something to show
up in that space (or a certain way) has more to do with
preserving the set of concerns and their meanings/significance
than with the relative "cheapness" of how it gets there.

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.

> 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.

-- 
Brad Appleton <brad@bradapp.net> www.bradapp.net
  Software CM Patterns (www.scmpatterns.com)
   Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 27 21:57:47 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.