Robert Simmons wrote:
>>systems like Perforce that use a single repository wide changeset
>>number, and they seem to get by. What's the big issue you have with it?
>
>
> I simply dislike it when I have low change
> rate in one software and the high change rate in another piece of software is
> driving the revision number through the roof. Subversion is only hovering around
> 7000. Put that in a corporate environment with 100 concurrent developers on 6
> tightly related projects and watch that number hit 100,000 in a ... MONTH. That
> would be EXTREMELY irritating. I am thinking of what happens when subversion
> hits a real test such as putting it in an office with such a large number of
> developers.
Well, I work in a corporate environment with about 100 developers
working on interconnected projects in a single perforce repository, and
nobody has a problem with the changeset numbers going up. Perhaps it is
a problem for you, but /in practice/ i have not observed it to be one.
>> 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.
No, it's not a flame. It's just my opinion based on my experience with
Subversion and other version control systems.
>>>What I would like to see is the concept of a project in the version control
>>>system where two projects can share the same repository and yet have
>
> different
>
>>>version numbers. You should be able to assign commit permissions on a
>>>per-project basis as well. (Although right now I don't even know how to
>
> assign
>
>>>authorization on repositories).
>>
>>In subversion authorization happens at a higher level than the
>>repository (currently).
>
>
> 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.
That's just great, but it doesn't change the fact that RIGHT NOW
Subversion does this stuff at a higher level than the repository. You
asked, I answered.
>>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.
Whoa there tiger, I think you've missed something about how to actually
get people to listen to you on an open source project mailing list.
Jumping in and pointing out how wrong everyone is without listening to
their reasons isn't likely to win you many friends.
Subversion has targeted the CVS userbase, and thus it's feature set is
similar, but better than, CVS's. Right now, that feature set is largely
frozen for 1.0. That's not to say these kind of issues won't get
resolved eventually, but I wouldn't bet on them changing right now.
>>There have been discussions about
>>more complex access controls that would be built into the repository,
>>but it's a post-1.0 issue.
>
>
> You will NEVER get in a corporate environment without this. <-- notice the
> period?
Judging from the amount of corporate environments that use CVS (a
considerable number), I think you're overestimating the problem. Yes,
there are people who will not use Subversion until these issues are
solved in a more satisfactory manner, but unless you're willing to sit
down and code it, I doubt it will happen right now.
> 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.
In summary, I would recommend you listen to some of the other Subversion
developers, who have spent a lot of time thinking about those issues,
and hear what they have to say. Perhaps you have something to
contribute, perhaps not, but jumping up and saying "you're wrong you're
wrong you're wrong" is not the best way to do it.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 22 00:49:05 2003