Brass Tilde wrote:
>>Apparently I have not explained myself sufficiently clearly...what I am
>>suggesting is that knowledge of the directories
>>trunk/tags/branches/release be built into the tools at the client end.
>
>
> And other people have said that would be a less than good thing, because not every development team does it that way. Even those
> who *do* do it that way may not do it in the same way. For instance, while we use the trunk/, tags/ and branches/ directory schema,
> ours are at the root of the repository instead of within each project. In addition, our releases/ branch appears under tags/,
> because our releases are static, never again to be worked on. Many people don't use anything resembling releases/ at all.
>
many don't perhaps, but many do. For a brief explanation of how many
organisations manage releases see chapter 5 of
http://svn.openehr.org/specification/TRUNK/publishing/CM/CM_plan.pdf,
which simply describes in minimal detail the concept of a release as a
branch whose further development is limited to bugfixes. Named
"releases" are tags of those release branches (admittedly the
terminology in CM is a bit confusing sometimes).
>
>>This would be done in such a way that they would no longer appear in the
>>'normal' directory hierarchy but instead would (for example) display the
>>contents of those directories as views, or in some other way. Then other
>>rules could be attached to those views, such as the rule that the tags
>>view is readonly after creation and so on. Doing this just enables the
>>machine to implement the discipline instead of humans having to do it,
>>which is the current case.
>
>
> As others have said, this would make the program directly responsible for enforcing the way *your* team works. As it stands right
> now, Subversion will already support your way of working, it just takes a little more work on your part. It also supports *my* way
> of working, and a host of others.
You are really missing the point here. What I am talking about is not
how "our" team works, it's more or less how CM is done. I am not of
course saying that there are not variations or no flexibility, but in a
mathematical sense, the relationship of mainline, alternate branches,
release branches, and tags is relatively well-defined. Not everyone
implements it the same way, but the intended logic is usually the same.
There are many publications in the CM area which describe these
concepts; all large organisations I have worked in have had the same
requirements for this aspect of CM.
Having this logic implemented in a flexible form would mean that you can
ignore it entirely and do your own thing. If used, it could be
configured according to particularities of the project (which is what
most commerccial CM systems allow). But many users I believe would like
accepted CM branching and tagging concepts supported outside of the
directory system, or at least in a way such that these meta-concepts did
not _appear_ in the directory system (even if they were, on the server
side).
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 30 14:03:47 2005