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.
People are looking for a CM system, and Subversion is not a CM system - it
is a source versioning database system. That's it.
I've been evaluating CA's Harvest product, and ClearCase. I can tell you
that underneath all the functionality is a source versioning system - the
value-add these products provide is a CM layer on top that regulates and
adds meta-information to versions, and regulates user interaction with the
versioning system.
That is a significant layer, but that is what it is. It also appears to be
a very expensive layer ;P. As a side note, it's a really complicated
product, but the CA (Harvest) product sure seems nice, although I'm not
sure I like how the actual source layer administration happens with this
product. They made it almost too hard to get to. It is, however, very easy
to model your entire development process (signoffs, roles, etc) in
Harvest, very very granular.
-----Original Message-----
From: Karan, Cem (Civ, ARL/CISD) [mailto:CKaran@arl.army.mil]
Sent: Wednesday, August 03, 2005 8:14 AM
To: brad@bradapp.net; users@subversion.tigris.org
Subject: RE: early reflections on subversion methodology
I would prefer to keep subversion's current repo-wide revision numbers.
Some of my coworkers are working with another system (VSS? Don't remember
for sure) and somehow they have it set so that each file has its own
revision number. I'm not sure what the whole situation was, but there was
a point where one developer walked in one day and announced to the whole
group that they were to cease using the repository while he grabbed out a
copy of the program that actually passed the tests...
something about commiting more files meant that he'd have to figure out
revision numbers on each file individually rather than just grabbing the
head...
If you want to start a project that builds on top of the subversion
libraries (but doesn't mess with SVN as it is) go for it; just please
DON'T do per-file or per-group revision # changes, they are just too
confusing...
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 3 17:51:17 2005