[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: Re: Re: How will policy branches work?

From: Boris
Subject: [Monotone-devel] Re: Re: Re: How will policy branches work?
Date: Wed, 06 Feb 2008 17:42:50 +0200
User-agent: Opera Mail/9.22 (Win32)

On Wed, 06 Feb 2008 14:51:27 +0200, Markus Schiltknecht <address@hidden> wrote:

Boris wrote:
It might be possible if policy settings and the list of administrators are stored in the database. Even if you have a copy of the database the database knows who the admininistrators are and will prevent others from changing the policy settings. Of course if administrators

Who are 'the administrators' in a distributed setting? I know, this might be very clear in a hierarchically organized company. However, for lots of open source projects, I would consider every single developer as the admin of his repository.

Yes, that's a different scenario. Ideally centralized permission settings are optional.

[...]If the files for these activation components are in the same branch, each revision maintains a hash over their contents. So, if the new co-worker is denied downloading those files, he cannot completely validate the revision. That would clearly speak for splitting those files into its own projects.

OTOH, that new co-worker cannot change these files, so monotone could simply skip the hash calculation for those files and reuse the existing hashes from the parent revision. I'm slowly beginning to think, that what you want here, is policy branches in conjunction with partial checkouts (where these activation component files are missing).

The problem is the co-worker shouldn't be allowed to check out the files at all. Management doesn't want anyone else except the responsible developers to see the source code. That would need to be guaranteed by the version control system - easy if it's a centralized one, arguably more difficult if it's a distributed one. I don't know if this will ever be possible with monotone (I don't even know if such a scenario is supported by any other distributed version control sytem) but these are the requirements I face. :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]