[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion Vision and Roadmap Proposal

From: Greg Stein <gstein_at_gmail.com>
Date: Sat, 10 Apr 2010 00:37:36 -0400

On Sat, Apr 10, 2010 at 00:18, Alexey Neyman <stilor_at_att.net> wrote:
> Have you looked at pre-commit hooks that may serve that purpose? I think
> svnperms.py may be what you're looking for - just disallow all operations
> except additions on 'tags/*', and disallow all operations on 'tags/*/*'.

I think people are asking about formalizing the trunks/tags/branches
("TTB") concepts (or some appropriate variant), and adding some
built-in technical enforcement of the concepts. Then some further
layering of merge handling within that restricted environment.

These kinds of changes would be quite welcome, I believe. "If you want
solid merge-tracking, both performant and easy, then do XYZ. There are
more open/flexible approaches, but those approaches come with issues."

I would like to add a very large nugget of history to this conversation:

Lest anybody say "damn. you guys fucked up with that design. should
have been more restricted from the start, so we wouldn't be in this
mess." Please recall that in the year 2000, when we started, the
version control of the day was CVS. NONE of these issues were anywhere
on the horizon. We set out to create a completely open and flexible
system, devoid of specific policy. We didn't know what would work
best. We didn't know what people needed or how they wanted to mold svn
to their particular development workflow. So we left it open, on
purpose. Even TTB was regarded as just a helpful layout.

Ten years later? Yup. We have a ton of input. We can fix a lot of
these things, and let people opt into these new solutions.

Cheers,
-g
Received on 2010-04-10 06:38:11 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.