On 8/3/05, Karan, Cem (Civ, ARL/CISD) <CKaran@arl.army.mil> wrote:
> I would prefer to keep subversion's current repo-wide revision numbers.
Are you currently using multiple related projects/products in the same
repository? (where each product has its own release labels, and may
also depend on certain release versions of other products?)
> Some of my coworkers are working with another system
> and somehow they have it set so that each file has
> its own revision number.
Yes - thats a very common problem with tools that do only
file-specific revisioning.
> just please DON'T do per-file or per-group revision # changes,
> they are just too confusing...
The problem you mentioned applies to per-file versioning. I dont
believe it applies to the proposed "per-group" versioning at all. I
suppose it would be possible to set-it-up in the worst case so that
every directory was a "versioned group", but I can do equally silly
things with externals and copies and so many other features of SVN.
The problem here is the multiple-project in a repository problem. If
the projects are never really related, meaning none of them are used
by any of the others - it may not be a problem. But then its likely
not an issue to make them all separate repositories either.
The problem arises when you have a bunch related projects/products, or
you have a set of "components" and you make multiple products/projects
form those components. Each product has its own releases and uses a
subset of "common" components as well as 1 or more components specific
to that project. So release-numbers need to be tracked that are
specific to each particular product, to the "core/common" set of
components, and to the entire product-line as a whole.
The "confusion" here is an inherent part of the problem itself. It
doesnt go away if I refrain from adding per-group versioning nor does
it go away if I do. repo-wide versioning doesnt solve it either. I can
try to solve this problem using SVN externals, which is essentially a
manual mechanism of implementing version-groups.
> Thanks,
> Cem Karan
>
> > -----Original Message-----
> > From: Brad Appleton [mailto:brad.appleton@gmail.com]
> > Sent: Tuesday, August 02, 2005 11:04 PM
> > To: users@subversion.tigris.org
> > Subject: Re: early reflections on subversion methodology
> >
> > Regarding revision-numbers versus tags ...
> >
> > Is it possible that repo-wide revision is the opposite
> > extreme from file-specific revisions? If version are
> > repo-wide, than it forces a certain mapping and usage
> > strategies for using multiple related projects or "components".
> >
> > If a repository is a file-system, does it make sense to have
> > some kind of not-to-coarse and not-to-fine granularity of
> > "grouping" that is somewhat less than the entire repository
> > and somewhat more than a single file?
> >
> > If it were a completely logical (as opposed to physical)
> > grouping, we'd have to allow "cherry picking" of individual
> > files and directories into logical "components" - which
> > sounds a bit too much of a stretch for the filesystem-based
> > versioning architecture.
> >
> > But if one chose a more physical (file-system centric) middle
> > point of granularity, then a subtree of the repository,
> > rooted at a particular directory, might be a good candidate.
> > The current externals mechanism allows mapping to something
> > that looks like this, tho its not quite the same thing.
> >
> > ClearCase/UCM had a similar type of issue. A "Vob" is a
> > mountpoint for a virtual filesystem. And early releases of
> > UCM had a notion of a "component", where components had to be
> > rooted at the top of the VOB (its mountpoint). Due to
> > increasing user demand, UCM later allowed so called "sub-Vob"
> > components, so long as they were rooted at a versioned
> > directory within the VOB.
> >
> > This would mean that revisions might be repo-wide, or could
> > be narrowed/pared down to a subtree. Recursion would be
> > interesting to handle, amd som ekind of inheritance mechanism
> > might need to be specified as to whether or not a revision of
> > a subtree would "percolate"
> > up to its its containing parent or not, and when/if the
> > parent version would simply map to an assembly of "sub
> > versions" (versions of subtrees)
> >
> > Then again, maybe the better way to handle it (particularly with
> > recursion) is the virtual repository of repositories model.
> > --
> > 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
>
>
--
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 Thu Aug 4 08:21:32 2005