Robert Simmons wrote:
>>"Garrett Rooney" <firstname.lastname@example.org> wrote in message
>> Generally, it seems that people's problem with it is psychological,
>>and in practice it isn't a real issue.
>Oh now that is a flame; shame on you. Im psychologically quite stable. Just
>because someone dislikes a thing doesnt mean they are crazy or unbalanced.
I think he was saying that the problem is psychological, not that people
who mention it has psychological problems ;-)
It bothered me for a little while, until I finally decided that the
version number has no bearing on the actual maturity of the repository
contents. The only real-world use it has is for describing a particular
repository state, i.e. "I'm running into this problem with subversion at
>Woah tiger. Im talkign about authorization, not authentication. Such as which
>developers can do what to which projects. Consider the 6 tightly integrated
>projects in a major development effort (well currently Im managing 9 but who'se
>counting?) All of these projects have hundreds of developers but I only want my
>GUI developers to have commit rights on GUI portions and so on. These are, in
>fact, more arguments for project concept.
>Authentication I am HAPPY to leave in the hands of LDAP, Apache and so on.
mod_authz_svn controls authorization against the subversion repository,
not authorization. Without this module, the granularity of authorization
is per-repository. (Note that this is fine for me, so I haven't really
looked at mod_authz_svn)
>>Either at the repository access layer (inside
>>Apache for ra_dav, or (in theory) svnserve in ra_svn), or in a hook
>>script that gets run before commits.
>I believe it shoudl be built in to the system and administerable by a trained
>monkey with a missing right hand. I know some network engineers in a corporate
>environment that would be lesser qualified than the monkey. They should be able
>to simply add usernames to commiter lists and not have to mess with scripts and
>whatnot. Stop thinking open source with people weaned on mothers milk and Perl.
>Start thinking corporate usage and brain dead morons that are, nevertheless, in
>charge and unavoidable.
Right now I have a simple password list that controls who has
repository-level access. Having more sophisticated access will wind up
requiring more competent people - even with a pretty gui, incompetent
people can mess what amounts to complex configuration rules up.
>In summary, subversion is wicked cool for open source but to capture the
>interest of coproations, it really needs some boost. Even when it comes to open
>source, the issue of projects remains. For example there are Apache Jakarta
>Commons libs that change daily and those that change rarely (because they are
>stable). Having revision number 1000000 of stable code that has worked since 200
>is silly. Similarly, splitting such closely related code into multiple
>repositories is silly. Well at least in my opinion and that of a couple
>collegues of mine. Somehow I dont think we are alone.
If you don't like high revision numbers, just ignore them. They have no
bearing other than to indicate changes in the state of the entire
Or illustrated a different way, you could conceivably alter subversion
to make the revision #s a 64-bit value based on microseconds since the
unix epoch. Assuming the clock never failed or went backwards in time
and that commits always took more than a microsecond, you would have
pretty much the same behavior - including very large numbers.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Oct 22 06:57:00 2003