> 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.
Glad to hear you like it. I dont; nor do several collegues I have talked to
about swapping out our version control system. =) Variety is lovely.
> >> 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.
Saying someone has a psychological problem because they disagree is a flame but
hey, I will drop it if you will.
> >>>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.
I am AWARE where it does this right now. I am simply saying I disagree with it
and on a practical level in a corporate environment it would be a little crazy.
Id have a real hard time convincing my bosses to trust apache for source
management security. Is it because my boss is wrong? Perhaps. However he is the
boss. If I, instead, told him we could put it on the repository as well or link
it up with LDAP, he would sign easily.
> >>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.
I am listening just fine. In fact I reply to you point by point. However a
discussion doesnt simply end because of your reasons. There is point and counter
point and so on. I am still waiting to hear counter points that say projects are
bad ideas. I have heard alot of you not personally thinking they are necessary
and you not personally missing them, but I havent heard any bad points about
having them.
Listening is a two way process. I try to listen to you and hope you will do me
the same courtesy. However listening to you doenst mean agreeing with you. I can
listen to you quite well and not agree. =)
> 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.
Judging from my experience as a consultant for 7 years and seeing all varieties
of abject stupidity I am probably UNDERSTATING the problem. How ever I am only
willing to meet the corporate stupidity half way. =)
> 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.
I would be happy to if I knew how. I would much rather write a 100% pure java
client library to allow more IDE integration. I am not one of those that isnt
wiling to put his time where his mouth is.
> > 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
I said I disagree, but so far we haven't even talked about any negative points
to projects. We have simply been discussing personal opinions on likes and
dislikes. I dislike red cars. You may love red cars. Does that mean you are
wrong? Of course not.
Now if you would like to bring some points against projects to the table, Id
love to discuss it. However, you may have the impression I am jumping up and
yelling you are wrong, I have the impression of strolling into an open source
project with ideas and being told to STFU and sit in the corner.
Lets hash out the pros and cons of projects and stop the hostility ok? Lets hear
your points on the theme "Projects would be bad for subversion because of ...."
-- Kraythe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 22 01:10:22 2003