Jonas Widarsson wrote:
> On Tuesday 04 January 2005 20:54, Christopher Ness wrote:
>> On Tue, 2005-04-01 at 20:36 +0100, Jonas Widarsson wrote:
>>> However, you speak of the commit procedure, and I want to filter
>>> checkouts.
>>
>> Simply make the directories you do not want to check out unreadable by
>> all users. If you can't read the directory - you can't check it out.
> Now, that sounds odd...
>>
>> Not sure why you'd want to do that... but it's your call.
> I don't. I wan't to define different exclusions for different sites, ie:
> site1 - exclude modules/app2, themes/app2
> site2 - exclude modules/app1, themes/app1
> Although on my laptop I check them both out with "site", which has no
> exclusions defined. That's pretty much like how cvs alias modules with !
> entries would work, although it only works on the initial checkout ...
> (I tried it. It was a halfway success)
>
> I don't really understand why people thinks this is so unusual. It would
> be
> great to manage code that is tightly assembled in one dimension and
> loosely
> in a second. Exclude the loose parts which don't apply.
> Now those checkouts with excluded subdirs aren't primarily for
> development,
> but for on site installation, with a possibility to commit if needed. I
> don't
> think it is so odd.
>
>> Personally I simply wouldn't put those directories under revision
>> control if they are different for each client. Maybe try a structure
>> like this.
>>
>> / -- trunk/
>> [ ... lengthy dirtree example ... ]
>>
>
> If exclusion was extremely important, I would go that way yes.
> This time it is more like a conveniency desire.
>
> Ah, I feel embarrased. You don't need to waste your time on this. Just
> know
> that there is a partly useful little feature in CVS (alias modules with
> subdir exclusion) that subversion doesn't have (yet).
>
> I am satisfied with the replies so far. I am not willing to wrestle with
> the
> system to get it working because it is not THAT important. I was looking
> for
> a simple method. There isn't one, so I leave my wish unfulfilled.
I agree, subversion needs to grow more features in this area.
A rough approximation to this could be crafted using svn:externals, but that
would get messy.
There is one other approach which might satisfy you, if you are already
using http:// access to the repository.
If you were to set up multiple user ids (one per customer), and use
mod_authz_svn to only grant read access for files that the relevant
customer's site needs, then any files to which access is denied should be
totally ignored. It's not a very elegant solution: you effectively need
seperate svn users for each module - but it would achieve the exclusions you
want. I leave you to decide whether it is worth the effort.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 5 12:39:38 2005