Robert Simmons wrote:
>>"Garrett Rooney" <rooneg@electricjellyfish.net> 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
rev xxxx".
>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
repository.
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.
-David Waite
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 22 06:57:00 2003