bruce wrote:
>geoff..
>
>ok.. thanks for your response....
>
>i can almost see where i could simply place the files in a single dir, and
>simply let the user 'update' their working copy to match the state of the
>repository... the issue with this approach is that the repository might grow
>upwards of > 1000 files... which is simply too much for the user to have to
>have this many files on their system, when they're only going to be dealing
>with a small subset of the files... so i'm going to need to use multiple
>dirs, with the requisite files.
>
>
>
Well, I think you are making this harder than necessary.
"upwards of 1000 files"?
My current repository is almost 4 gig and contains 26,000 files in 7,700
directories.
We work mainly from laptops, a full pull from the repository takes about
45 minutes the first time
later updates either from or to the repository takes 3-5 minutes.
We all have a complete working copy.
I don't know what your 'code' is or how it's tested but my lowly
'web-app' still has interdependencies
which really require a complete working copy to do valid development and
testing.
A kludge to 'save' maybe 10 minutes a day will cost much more in my time
to hack up some other more
complicated process to work with subsets of files and will undoubtedly
lead to problems with development and
testing being done in isolation from the real and complete source base.
My 2 cents...
As to your permissions issue, I'd take a different approach.
In my system we have several departments that can check 'stuff' into the
repository.
'health and safety' literature updated on a regular basis like 'wear
your hard hat' kind of stuff in PDF files.
'H.R.' posts word documents containing job postings.
We have about nine groups like this in addition to the development group.
I simply built 9 repositories with the 'master' being the one belonging
to the development group and include
the other projects using the subversion external functionality.
As to individual developer rights, the place to manage that is via the
pre-commit triggers.
They can call arbitrary code to do absolutely anything you want to
validate and approve a check-in.
Not only could you build an access rights database that would be a dream
to administer compared to apache
lists done by hand but you could extend it using all sorts of logic.
We have an issue and work flow tracking system used to manage
development here.
Bugs or problems are entered into the system.
System Change Requests are generated, validated, examined to determine
scope and the files which will probably
need to be modified. Those SCRs are then assigned to developers,
testers, integrators and installers.
I have no desire to manage a separate access list which will be changing
all the time anyway.
A pre-commit hook script could readily hit the SCR database, look at the
SCRs assigned to said developer and
allow or reject the changes based on the files he should be working on
currently.
The logic here could be as lax or draconian as necessary in your situation.
You could simply 'log' questionable changes for later review.
You could email a notice of violation to appropriate parties and allow
the commit.
Do the same and reject the commit.
Call in an air-strike on his MAC address.... whatever.
The other extreme is this is a revision control and tracking system if
Dufus changes something he shouldn't there
will be a permanent record of it so as to assign blame after the fact.
In reality this is enough control for professionals, IMHO.
Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 25 18:20:04 2004