RE: Archiving Projects (End-Of-Life)

[Bob Archer]

> I'm wondering if there is a (de-facto) standard way of "end-of-
> lifing"
> projects in an SVN repository, or any suggestions for this from
> other
> users on this list ...
> 
> With End-Of-Life I mean there will be no further maintenance on
> that
> project, no more development, no more releases or patches, no more
> users. It's really dead. But sometimes one might want to take a
> look
> at the old code, check out its history, maybe even resurrect it,
> ...
> I would like to get those projects out of sight, so it's more clear
> what the active projects are. (I'm not talking about
> "obliterating",
> to reclaim disk space or anything like that, quite the contrary: I
> want to have them still available, just ... less visible).
> 
> I know I could just "svn rm" them, but some of the "project owners"
> feel a little bit uneasy about that. They consider it "probable"
> that
> they will need to take another look at them sometime in the future.
> And as we all know, it's not so easy to find a deleted
> file/directory/project again (to find out what the latest revision
> was
> in which the project still existed).
> 
> My repository is currently structured as:
> 
> trunk
>   \--project1
>   \--project2
>   \--...
> branches
> tags
> 
> But I think the question is more or less the same if it's
> structured
> in the other standard way (projects/TTB).
> 
> Currently I have two options in mind:
> - Move the EOL'ed projects to a new directory "archive", a new
> "root"
> directory next to TTB.
> - Move the EOL'ed projects to a tag (maybe also in an "archive"
> subdirectory, under tags). If it ever needs to be resurrected, it
> can
> be easily copied from that tag.
> 
> Thoughts? Other ideas? Pros and cons?
> 

Two options I can think of.. one simple, one will need admin access...

1. Create a folder in your repository named (end of life) and move the project 
folder there.

2. Dump the repository, use dumpfilter and import it into an "end of life" 
repository, then RM it from your main repo.

BOb

Re: Archiving Projects (End-Of-Life)

[David Weintraub]

On Mon, Dec 13, 2010 at 3:04 PM, Johan Corveleyn  wrote:
> Hi,
>
> I'm wondering if there is a (de-facto) standard way of "end-of-lifing"
> projects in an SVN repository, or any suggestions for this from other
> users on this list ...
>>
> I know I could just "svn rm" them, but some of the "project owners"
> feel a little bit uneasy about that.

Do they know that doing a "svn rm" doesn't actually remove those
projects from the repository? All "svn rm" does is remove them from
the HEAD of the repository. They can still access all the history,
tags, branches and what not by simply using the -r 
parameter when you do a Subversion command. And, they can find out the
revision by doing a "svn log".

However, if that's to scary for them, create an "obsolete" folder and
move all the projects in there. Then, via pre-commit hook or
configuration, make all files and directories under "obsolete"
read-only:

+--obsolete (Whole subtree is read only)
| |
|   trunk
|   branches
|   tags
|
+--trunk (Still read/write)
+--branches (Still read/write)
+--tags (Still read/write)

That'll get the files out of the main project tree, prevent further
changes in the code, yet still allow the developers to examine the
code and reminisce about the good ol' days when men were men and UUCP
was king.

-- 
David Weintraub
qazw...@gmail.com

Re: Archiving Projects (End-Of-Life)

[Ulrich Eckhardt]

On Monday 13 December 2010, Johan Corveleyn wrote:
> I'm wondering if there is a (de-facto) standard way of "end-of-lifing"
> projects in an SVN repository, or any suggestions for this from other
> users on this list ...
>
> With End-Of-Life I mean there will be no further maintenance on that
> project, no more development, no more releases or patches, no more
> users. It's really dead. But sometimes one might want to take a look
> at the old code, check out its history, maybe even resurrect it, ...
> I would like to get those projects out of sight, so it's more clear
> what the active projects are. (I'm not talking about "obliterating",
> to reclaim disk space or anything like that, quite the contrary: I
> want to have them still available, just ... less visible).

Just rm the trunk. You might even want to rm the branches, depending on 
whether the projects still receive a minimal amount of maintenance.

> [...] as we all know, it's not so easy to find a deleted
> file/directory/project again (to find out what the latest revision
> was  in which the project still existed).

In that case, you could move it.

In any case, the old relocation rule applies. Any box not unpacked after a 
year should be thrown away without even taking a look at the content. You 
didn't need it anyway. ;^)

Uli


-- 
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/


**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

Re: Archiving Projects (End-Of-Life)

[Thorsten Schöning]

Guten Tag Johan Corveleyn,
am Montag, 13. Dezember 2010 um 21:04 schrieben Sie:

> I know I could just "svn rm" them, but some of the "project owners"
> feel a little bit uneasy about that. They consider it "probable" that
> they will need to take another look at them sometime in the future.
> And as we all know, it's not so easy to find a deleted
> file/directory/project again (to find out what the latest revision was
> in which the project still existed).

I personally totally agree with that and wouldn't delete the projects
either, unless pretty sure it's uninteresting.

> trunk
>   \--project1
>   \--project2
>   \--...
> branches
> tags
[...]
> Currently I have two options in mind:
> - Move the EOL'ed projects to a new directory "archive", a new "root"
> directory next to TTB.
> - Move the EOL'ed projects to a tag (maybe also in an "archive"
> subdirectory, under tags). If it ever needs to be resurrected, it can
> be easily copied from that tag.

> Thoughts? Other ideas? Pros and cons?

In my mind it really depends on the directory structure in the
repository one uses. If you just have trunk/project 1 to n an for
example no tags|branches/project 1 to n I would create an
archive|obsolote|eol|whatever folder in tags and move each project
with eol in there. If you have tags|branches/project 1 to n I would
prefer keeping the TTB-structure as is and create, as you suggested,
a new root folder archive|... and recreate the TTB-structure for each
project in there. Depending on your development environment using the
same directory structure you already work with, just in a different
level, may help you in running, building or whatever your old
projects, if wanted. If it's more interesting to see which projects
are out of life in the first way, a new root directory with project
specific sub directory with TTB in there could be an alternative. I
would decide regarding my development environment.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoen...@am-soft.de
Web: http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow

RE: Archiving Projects (End-Of-Life)

[Giulio Troccoli]

>


Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03

-Original Message-


> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: 13 December 2010 20:04
> To: users@subversion.apache.org
> Subject: Archiving Projects (End-Of-Life)
>
> Hi,
>
> I'm wondering if there is a (de-facto) standard way of "end-of-lifing"
> projects in an SVN repository, or any suggestions for this
> from other users on this list ...
>
> With End-Of-Life I mean there will be no further maintenance
> on that project, no more development, no more releases or
> patches, no more users. It's really dead. But sometimes one
> might want to take a look at the old code, check out its
> history, maybe even resurrect it, ...
> I would like to get those projects out of sight, so it's more
> clear what the active projects are. (I'm not talking about
> "obliterating", to reclaim disk space or anything like that,
> quite the contrary: I want to have them still available, just
> ... less visible).
>
> I know I could just "svn rm" them, but some of the "project owners"
> feel a little bit uneasy about that. They consider it
> "probable" that they will need to take another look at them
> sometime in the future.
> And as we all know, it's not so easy to find a deleted
> file/directory/project again (to find out what the latest
> revision was in which the project still existed).
>
> My repository is currently structured as:
>
> trunk
>   \--project1
>   \--project2
>   \--...
> branches
> tags
>
> But I think the question is more or less the same if it's
> structured in the other standard way (projects/TTB).
>
> Currently I have two options in mind:
> - Move the EOL'ed projects to a new directory "archive", a new "root"
> directory next to TTB.
> - Move the EOL'ed projects to a tag (maybe also in an "archive"
> subdirectory, under tags). If it ever needs to be
> resurrected, it can be easily copied from that tag.
>
> Thoughts? Other ideas? Pros and cons?

Maybe I'm missing something, but since you have a tags directory I guess you 
did tag your last release of the project. So why not just simply (svn) delete 
the project from trunk? The whole history is preserved in the latest tag for 
that project, is it not?

Giulio

RE: Archiving Projects (End-Of-Life)

[Cooke, Mark]

> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@gmail.com] 
> Sent: 13 December 2010 20:04
> To: users@subversion.apache.org
> Subject: Archiving Projects (End-Of-Life)
> 
> Hi,
> 
> I'm wondering if there is a (de-facto) standard way of "end-of-lifing"
> projects in an SVN repository, or any suggestions for this from other
> users on this list ...
> 
> With End-Of-Life I mean there will be no further maintenance on that
> project, no more development, no more releases or patches, no more
> users. It's really dead. But sometimes one might want to take a look
> at the old code, check out its history, maybe even resurrect it, ...
> I would like to get those projects out of sight, so it's more clear
> what the active projects are. (I'm not talking about "obliterating",
> to reclaim disk space or anything like that, quite the contrary: I
> want to have them still available, just ... less visible).
> 
> I know I could just "svn rm" them, but some of the "project owners"
> feel a little bit uneasy about that. They consider it "probable" that
> they will need to take another look at them sometime in the future.
> And as we all know, it's not so easy to find a deleted
> file/directory/project again (to find out what the latest revision was
> in which the project still existed).
> 
> My repository is currently structured as:
> 
> trunk
>   \--project1
>   \--project2
>   \--...
> branches
> tags
> 
> But I think the question is more or less the same if it's structured
> in the other standard way (projects/TTB).
> 
> Currently I have two options in mind:
> - Move the EOL'ed projects to a new directory "archive", a new "root"
> directory next to TTB.
> - Move the EOL'ed projects to a tag (maybe also in an "archive"
> subdirectory, under tags). If it ever needs to be resurrected, it can
> be easily copied from that tag.
> 
> Thoughts? Other ideas? Pros and cons?
> 
I use separate repos (using parent path) for all projects unless closely
related, and this is one of the main reasons why I do so.  A little bit
of extra work when creating new projects is a lot simpler than
dumpfiltering projects out late in the lifecycle.

I'd be interested in any strong arguments for using one repo over many!

~ mark c

Re: Archiving Projects (End-Of-Life)

[Ulrich Eckhardt]

On Tuesday 14 December 2010, Cooke, Mark wrote:
> I'd be interested in any strong arguments for using one repo over many!

You don't need svnadmin to create a new project.

That was simple! :'D

Uli

-- 
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/


**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

RE: Archiving Projects (End-Of-Life)

[Cooke, Mark]

> On Tuesday 14 December 2010, Cooke, Mark wrote:
> > I'd be interested in any strong arguments for using one 
> > repo over many!
> 
> -Original Message-
> From: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com] 
> Sent: 14 December 2010 10:53
> To: users@subversion.apache.org
> Subject: Re: Archiving Projects (End-Of-Life)
> 
> You don't need svnadmin to create a new project.
> 
> That was simple! :'D
> 
> Uli
> 
...but I don't see that as a problem for us, it's just a little pain
occasionally for a big gain in the end.

Plus, for us, we usually have linked Trac environments, so that needs to
be created as well.  In fact, having linked trac projects is another
reason why I like the lack of revision number churn caused by unrelated
projects.

~ mark c

Re: Archiving Projects (End-Of-Life)

[Johan Corveleyn]

On Tue, Dec 14, 2010 at 11:58 AM, Cooke, Mark  wrote:
>> On Tuesday 14 December 2010, Cooke, Mark wrote:
>> > I'd be interested in any strong arguments for using one
>> > repo over many!
>>
>> -Original Message-
>> From: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com]
>> Sent: 14 December 2010 10:53
>> To: users@subversion.apache.org
>> Subject: Re: Archiving Projects (End-Of-Life)
>>
>> You don't need svnadmin to create a new project.
>>
>> That was simple! :'D
>>
>> Uli
>>
> ...but I don't see that as a problem for us, it's just a little pain
> occasionally for a big gain in the end.
>
> Plus, for us, we usually have linked Trac environments, so that needs to
> be created as well.  In fact, having linked trac projects is another
> reason why I like the lack of revision number churn caused by unrelated
> projects.
>
> ~ mark c
>

In our case, code sometimes migrates from one project to another (the
projects are closely related, or put another way: there are a lot of
dependencies among them).

For instance: we have a "common" project, with the common utilities
used by other projects. Sometimes, some new utility code is written in
one of the projects (starts out as being useful for that single
project), and after a while, they see that it could be useful for
other projects as well. So the stuff is moved to the common project,
without losing history etc.

We don't care about revision number churn ...

-- 
Johan

Re: Archiving Projects (End-Of-Life)

[Nick Stolwijk]

You cannot easily refactor code into seperate modules, used by
multiple projects, with keeping of history.

Another easy one. ;)

Hth,

Nick Stolwijk
~Senior Java Developer~

iPROFS
Wagenweg 208
2012 NM Haarlem
T +31 23 547 6369
F +31 23 547 6370
I www.iprofs.nl



On Tue, Dec 14, 2010 at 11:02 AM, Cooke, Mark  wrote:
>> -Original Message-
>> From: Johan Corveleyn [mailto:jcor...@gmail.com]
>> Sent: 13 December 2010 20:04
>> To: users@subversion.apache.org
>> Subject: Archiving Projects (End-Of-Life)
>>
>> Hi,
>>
>> I'm wondering if there is a (de-facto) standard way of "end-of-lifing"
>> projects in an SVN repository, or any suggestions for this from other
>> users on this list ...
>>
>> With End-Of-Life I mean there will be no further maintenance on that
>> project, no more development, no more releases or patches, no more
>> users. It's really dead. But sometimes one might want to take a look
>> at the old code, check out its history, maybe even resurrect it, ...
>> I would like to get those projects out of sight, so it's more clear
>> what the active projects are. (I'm not talking about "obliterating",
>> to reclaim disk space or anything like that, quite the contrary: I
>> want to have them still available, just ... less visible).
>>
>> I know I could just "svn rm" them, but some of the "project owners"
>> feel a little bit uneasy about that. They consider it "probable" that
>> they will need to take another look at them sometime in the future.
>> And as we all know, it's not so easy to find a deleted
>> file/directory/project again (to find out what the latest revision was
>> in which the project still existed).
>>
>> My repository is currently structured as:
>>
>> trunk
>>   \--project1
>>   \--project2
>>   \--...
>> branches
>> tags
>>
>> But I think the question is more or less the same if it's structured
>> in the other standard way (projects/TTB).
>>
>> Currently I have two options in mind:
>> - Move the EOL'ed projects to a new directory "archive", a new "root"
>> directory next to TTB.
>> - Move the EOL'ed projects to a tag (maybe also in an "archive"
>> subdirectory, under tags). If it ever needs to be resurrected, it can
>> be easily copied from that tag.
>>
>> Thoughts? Other ideas? Pros and cons?
>>
> I use separate repos (using parent path) for all projects unless closely
> related, and this is one of the main reasons why I do so.  A little bit
> of extra work when creating new projects is a lot simpler than
> dumpfiltering projects out late in the lifecycle.
>
> I'd be interested in any strong arguments for using one repo over many!
>
> ~ mark c
>

Re: Archiving Projects (End-Of-Life)

[Thorsten Schöning]

Guten Tag Nick Stolwijk,
am Dienstag, 14. Dezember 2010 um 12:03 schrieben Sie:

> Another easy one. ;)

Using separate repositories for projects makes access control a lot
easier and safer: Depending on using svnserve, one has the chance to
use different instances for svnserve on different ports for different
projects. We for example have divided our projects into source and
binary projects, one for internal, one for internal and external use,
with (nearly?) no chance that an external user can gain access to the
internal repositories or any other port/service running on the
svn-server.

In one repository created users can't accidently gain access to
repositories which they shouldn't get access on.

Hooks can be managed on a per project base and you don't need to write
UML for hooks just because you have 20 projects with different needs
pre or post a commit.

Maintenance if some problem occurs which needs dumping and loading or
stuff like that is easier and faster.

First page in WebSVN is descriptive to users out of the box.

It's as always, if to decide what to centralize and what not...

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoen...@am-soft.de
Web: http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow

Re: Archiving Projects (End-Of-Life)

[Johan Corveleyn]

On Mon, Dec 13, 2010 at 10:23 PM, David Weintraub  wrote:
> On Mon, Dec 13, 2010 at 3:04 PM, Johan Corveleyn  wrote:
>> Hi,
>>
>> I'm wondering if there is a (de-facto) standard way of "end-of-lifing"
>> projects in an SVN repository, or any suggestions for this from other
>> users on this list ...
>>>
>> I know I could just "svn rm" them, but some of the "project owners"
>> feel a little bit uneasy about that.
>
> Do they know that doing a "svn rm" doesn't actually remove those
> projects from the repository? All "svn rm" does is remove them from
> the HEAD of the repository. They can still access all the history,
> tags, branches and what not by simply using the -r 
> parameter when you do a Subversion command. And, they can find out the
> revision by doing a "svn log".
>
> However, if that's to scary for them, create an "obsolete" folder and
> move all the projects in there. Then, via pre-commit hook or
> configuration, make all files and directories under "obsolete"
> read-only:
>
> +--obsolete (Whole subtree is read only)
> |     |
> |   trunk
> |   branches
> |   tags
> |
> +--trunk (Still read/write)
> +--branches (Still read/write)
> +--tags (Still read/write)
>
> That'll get the files out of the main project tree, prevent further
> changes in the code, yet still allow the developers to examine the
> code and reminisce about the good ol' days when men were men and UUCP
> was king.

Thanks for the suggestions, all. I think I'm gonna go for David's
suggestion here above. I.e. create a top-level "obsolete" directory
with TTB inside, and "svn mv" the obsolete stuff in there.

I'll take a look at making the obsolete directory "read-only" (or
add-only, like for tags). Thanks to David, I have this great perl
script lying around, which can be easily configured to enforce this
from my pre-commit hook :-).

Cheers,
-- 
Johan

Re: Archiving Projects (End-Of-Life)

[Andy Levy]

On Wed, Dec 15, 2010 at 06:44, Johan Corveleyn  wrote:
> On Mon, Dec 13, 2010 at 10:23 PM, David Weintraub  wrote:
>> On Mon, Dec 13, 2010 at 3:04 PM, Johan Corveleyn  wrote:
>>> Hi,
>>>
>>> I'm wondering if there is a (de-facto) standard way of "end-of-lifing"
>>> projects in an SVN repository, or any suggestions for this from other
>>> users on this list ...

>>> I know I could just "svn rm" them, but some of the "project owners"
>>> feel a little bit uneasy about that.
>>
>> Do they know that doing a "svn rm" doesn't actually remove those
>> projects from the repository? All "svn rm" does is remove them from
>> the HEAD of the repository. They can still access all the history,
>> tags, branches and what not by simply using the -r 
>> parameter when you do a Subversion command. And, they can find out the
>> revision by doing a "svn log".
>>
>> However, if that's to scary for them, create an "obsolete" folder and
>> move all the projects in there. Then, via pre-commit hook or
>> configuration, make all files and directories under "obsolete"
>> read-only:
>>
>> +--obsolete (Whole subtree is read only)
>> |     |
>> |   trunk
>> |   branches
>> |   tags
>> |
>> +--trunk (Still read/write)
>> +--branches (Still read/write)
>> +--tags (Still read/write)
>>
>> That'll get the files out of the main project tree, prevent further
>> changes in the code, yet still allow the developers to examine the
>> code and reminisce about the good ol' days when men were men and UUCP
>> was king.
>
> Thanks for the suggestions, all. I think I'm gonna go for David's
> suggestion here above. I.e. create a top-level "obsolete" directory
> with TTB inside, and "svn mv" the obsolete stuff in there.
>
> I'll take a look at making the obsolete directory "read-only" (or
> add-only, like for tags). Thanks to David, I have this great perl
> script lying around, which can be easily configured to enforce this
> from my pre-commit hook :-).

If you just need to set the whole directory read-only unilaterally,
you don't need a pre-commit hook; just use the built-in path-based
authorization.

Re: Archiving Projects (End-Of-Life)

[Nico Kadel-Garcia]

On Wed, Dec 15, 2010 at 8:50 AM, Andy Levy  wrote:

> If you just need to set the whole directory read-only unilaterally,
> you don't need a pre-commit hook; just use the built-in path-based
> authorization.

Well, no, you don't *need* to do it that way. But each access method
has its own access control, whether svn or svn+ssh, file based, or
http/https. Rather than exerting cleverness, simply disabling all
writes in a clean and easily restored fashion, and one that is more
certain to be replicated by an svnadmin hotcopy, seems quite
reasonable.

Re: Archiving Projects (End-Of-Life)

[David Weintraub]

> On Wed, Dec 15, 2010 at 8:50 AM, Andy Levy  wrote:
>
> If you just need to set the whole directory read-only unilaterally,
> you don't need a pre-commit hook; just use the built-in path-based
> authorization.

On Thu, Dec 16, 2010 at 12:57 AM, Nico Kadel-Garcia  wrote:
> Well, no, you don't *need* to do it that way. But each access method
> has its own access control, whether svn or svn+ssh, file based, or
> http/https. Rather than exerting cleverness, simply disabling all
> writes in a clean and easily restored fashion, and one that is more
> certain to be replicated by an svnadmin hotcopy, seems quite
> reasonable.

There are advantages to path based authorization and using a pre-commit hook.

One advantage with path-based authorization is that you can create
read (or more importantly "non-read" access). You can't do that with a
hook.

Path based authorization also uses fewer resources than a pre-commit
hook. With path based authorization, the Subversion server can do the
authorization as it does whatever processing it needs. With a
pre-commit hook, the server has to run another program. Most
pre-commit hooks run on an "O-squared" algorithm. Each file must be
tested against each permission. If you are committing a few files, and
you only have a few rules, the pre-commit hook is barely noticeable.
But if you're committing thousands of files and checking them against
thousands of arcane permissioning rules, your pre-commit hook
execution time might start hitting the nuisance zone.

However, a pre-commit hook has certain advantages. With a path based
authorization and Apache, you have to bounce the server every time you
change permissions. This can be difficult to do. Plus, changing the
permissions might require approval of other individuals and
departments since you're changing the Apache configuration.

With a pre-commit hook, changing permissions is instantaneous and
requires simply modifying the pre-commit hook configuration file.
Something most Subversion admins can do on their own.

Also a pre-commit hook puts the authorization in the Subversion
repository directory where it gets backed up on a regular basis. If
your Subversion server crashes and has to be rebuilt, you might not
remember a highly detailed path-based authorization, but your
pre-commit hook authorization list is safely backed up.

Also, a pre-commit hook can do "add-only" authorization. This allows
users to create a tag, but not modify the tag once it is created. A
similar thing could be done with this "obsolete" directory: Technical
leads can add branches and maybe projects into the "obsolete"
directory, but no one can modify a file once it is there.

My general rule of thumb is to setup gross permissions with the path
based authorization -- especially those that depend upon no read
access. For example, only people in the LDAP developer group can
access our Subversion server, and only people in this department can
modify their directory tree , but other developers will be able to
read it.

>From there, I use a pre-commit hook to fine tune it. For example,
locking a branch or tag to prevent its modification. Or allowing only
a few select users the ability to modify a release branch. This is
mainly to prevent whoops scenarios. For example, a developer
forgetting to "svn switch" from the branch to the trunk before they
continue their development work.

-- 
David Weintraub
qazw...@gmail.com