RE: early reflections on subversion methodology

> 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?)

Yes, which is why I want the whole repo-wide version numbering system. Invariably, someone adds a new feature (or breaks an old one) that causes the whole project to start failing regression tests, and I need to be able to roll everything back easily.

> > 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.

I see your point, as that is exactly the sort of thing that is going on; we have a core set of utility 'libraries' which, if broken, cause all the other projects to go haywire. The problem is that if you have a per-group revision number, you need to be able to have other groups be aware that they are working against a group. I.e., if I have groups A, B, and C, when I commit a revision of group A that depends on B and C, I need to able to state that A depends on B::234 and C::38, and have that built into the commit command. If you don't do this, then it becomes more of a problem then a solution.

As it stands, by putting it all into one repository (and keeping track of the revision number that last worked for me) I can always see where things broke. If you want to make it so that I can roll back a group of files (E.g., 'svn merge -r B::head:B::234') or update to an older set of files (E.g., 'svn up -r B::234') or make it so that updates/commits/etc. are per-group dependent, then I can see where you are going.

I would rather see all of this built on top of the SVN libraries rather than into them though...

Thanks,
Cem Karan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 4 13:55:11 2005