Re: early reflections on subversion methodology

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

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

> But if it were there, I think most users would choose to use it.

I've seen no proof of that. There is a relatively easy way to prove it though, simply build a client that does the things you want,
and see if "most users [...] choose to use it."

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 29 14:31:35 2005