[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Projects?

From: Robert Simmons <derisor_at_arcor.de>
Date: 2003-10-22 00:34:14 CEST

> "Garrett Rooney" <rooneg@electricjellyfish.net> wrote in message
news:3F95B05E.4030201@electricjellyfish.net...
> Robert Simmons wrote:
>
> > Once again, I am sorry if I'm hitting things that have been discussed but
maybe
> > they need to be discussed again. =)
> >
> > At any rate, I enjoy the new revision system in subversion except for one
small
> > detail. The problem is that with this revision I can t have two projects in
the
> > same repository without them both having the same revision number no matter
how
> > many times they have changed independently. The result is to create multiple
> > repositories. However, there are situations where projects are related and
> > should be located in the same repository.
>
> Well, let's throw it back to you: Why do you need separate revision
> numbers for each project? There are a huge amount of people using

Need? Need is the wrong word to use. Simply desire. I would bet that I am not
alone in that desire. In fact I dont NEED to change version control systems. I
merely desire to.

> 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?

Every day some 10,000 people world wide get in their car and drive drunk. That
doesnt mean its an especially good idea. Just because "others" do something
doesnt mean I wish to do it as well. 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.

> 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.

> > 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.

Authentication I am HAPPY to leave in the hands of LDAP, Apache and so on.

> 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.

> 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?

> -garrett

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.

-- 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 00:35:00 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.