On Saturday 10 April 2010 01:57:32 pm Vadim Chekan wrote:
> On Fri, Apr 9, 2010 at 9:37 PM, Greg Stein <gst...@gmail.com> wrote:
> > On Sat, Apr 10, 2010 at 00:18, Alexey Neyman <sti...@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."
>
> Thanks Greg, exactly what I mean.
> I *do* like flexibility: life is crazy and you never know what
> configuration you'll need in your next project. So it would be good to
> preserver the current svn ability to work with any folder as with TTB.
> If possible.
> BUT: I want svn to reflect the way 99% of programmers work 99% of their
> time. If explicit branching can help to simplify merging algorithms,
> great. Tagging can prevent newbies (or absent minded pros) from modifying
> released code - great!
I am not against standardizing most common approach. I just think it would be
wasteful to focus on the issues that could be easily dealt with by configuring
the repository.
Here's an idea: have 'svnadmin create' populate the hooks that will perform
enforcement of some of the desired models. E.g.:
$ svnadmin create --model=none <PATH>
[default] Creates an empty hooks area, allows for the flexible configuration
$ svnadmin create --model=ttb <PATH>
Creates /{trunk,tags,branches} directories in the repo, adds hook scripts that
enforce tag immutability.
$ svnadmin create --model=project_ttb <PATH
Same as above, for the /{PROJECT1,PROJECT2}/{trunk,tags,branches} layout.
These should provide good starting point for most projects, then the
repository admin could fine-tune the settings as he likes it.
Why I don't see these issues as a high priority? Let me quote from the first
email in this thread:
=====================
.... What's more, huge classes of users remain categorically opposed to the
very tenets on which the DVCS systems are based. They need centralization.
They need control. They need meaningful path-based authorization....
=====================
Yet, one the core features for a centralized VCS is postponed once again:
=====================
1.8: repository-dictated configuration
=====================
Even CVS had the ability to (a) customize keyword expansion and (b) provide
custom log message templates. These features, as far as I remember, were first
targeted as "pre-1.0" and are postponed ever since.
Best regards,
Alexey.
