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
Received on Wed Aug 3 14:17:36 2005