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:04:46 2005