RE: early reflections on subversion methodology

G'day Thomas,

<apologies for the HTML formatted email - I'm using a web based emailer that doesn't give me control over the format of my email>

Perhaps I'm missing something, but if a particular revision is important for some reason (eg. for rollback purposes), why wouldn't you create a copy ("tag") of that revision elsewhere in the tree? That copy could (through the use of commit hooks) be read only, if that's a requirement. The nice thing is that instead of being a hard-for-humans-to-remember integer, this important revision would have a symbolic name (the SVN URL) that is likely to have a lot more meaning.

I guess I'm still missing why having a single tree that contains both the "special" namespaces (branches, tags what-have-you) as well as the contents of those namespaces is such a problem. Sure the system doesn't necessarily understand the differing semantics of these constructs, but I don't see why it would need to.

I've heard it said that a lot of software design is about striking the right balance between systematically enforced rules (which are inviolable but inflexible), and procedurally enforced guidelines (which are flexible, but more difficult to enforce), and it seems to me that Subversion pushes that decision out to its users (which, IMVHO, is ideal). I can go with the default mechanism where the "special" namespaces are up to me to define and enforce procedurally, or (through the use of such things as pre-defined repository structures and commit hooks) I can systematically enforce a particular CM metholodogy. Regardless, the key point is that Subversion doesn't lock me into either scheme.

Cheers,
Peter

----------------------------------------------------------------------
Peter Monks http://www.sydneyclimbing.com/
pmonks_at_sydneyclimbing.com http://www.geocities.com/yosemite/4455/
----------------------------------------------------------------------

From: Thomas Beale
Sent: Fri 12-Aug-05 10:56 am
To: users@subversion.tigris.org
Subject: Re: early reflections on subversion methodology

ed.wittmann@fiserv.com wrote:
> Repo-wide revisioning is not an extreme - it's just a different way of
> looking at it. It doesn't matter what changes cause a revision - all you
> need to know is the revision number, and the revision right before it.
>
> It's the confusion about this and lack of a perceived structure to
> branching and tagging that is leaving large-scale projects and neophyte
> users wanting more - hence the need for a layer on top of Subversion.

If anyone is any doubt, consider that an increment in revision (in the
CM sense) really only has any meaning when applied to a single line of
development of a product/project, i.e. the whole tree corresponding to
the main line, a particular branch, or a particular release (which are
almost always some variant of each other). Then each revision number
corresponds to a change in the controlled content.

But when there are multiple lines of development in the same versioned
space (such as subversion provides), an increment in revision number
probably corresponds to a change in only one of them, or it might be
many - it is arbitrary. Although this might in fact be a desirable
possibility in a highly functional system (e.g. "apply security path 159
to every variant of the system"), it bypasses the basic functionality
that is needed.

In today's subversion, the revision number keeps incrementing, even if
you do nothing on your line of development - even if it is the mainline
with 100 developers (maybe the bug-fixers on release-1.1 are madly
working to fix bugs on that release). This fact alone means that the
revision number can be assumed to have no meaning at all. Which means
that to get a revision number of a given product in a given line of
development, you have to do something extra yourself.

Subversion's revision numbers are only meaningful as ids of checkpoints
in the history of the file system being versioned - almost an OS level
thing - similar to the way versioned databases behave. Excellent, but
not that useful at the CM level.

- thomas beale

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 12 20:42:48 2005