Markus Schiltknecht [EMAIL PROTECTED] writes:
What you can (already) do is preventing him to upload that branch to
your (or the company's central) repository.
I don't see how to do this on a branch basis.
The syntax of ~/.monotone/write-permission only allows specifying
users, not branches.
Hi,
Stephen Leake wrote:
I don't see how to do this on a branch basis.
The syntax of ~/.monotone/write-permission only allows specifying
users, not branches.
Correct, sorry for the noise, I mixed things up.
How do I specify that abe is allowed to upload branch foo, but not
any other
Hi,
Brian May wrote:
I don't think it is possible to restrict the branches somebody can
push; either they have full write access or no write access.
Uh.. right, of course. Sorry for the noise.
And netsync even propagates revisions around, it doesn't trust itself.
Big time for nuskool, IMO.
On Tue, 05 Feb 2008 19:30:28 +0200, Zack Weinberg [EMAIL PROTECTED] wrote:
[...]Because this is a distributed VCS, we can't, ultimately, prevent
people from doing whatever they want to their own copy of the
It might be possible if policy settings and the list of administrators are
stored in
Hello,
I'm thinking of making a release pretty soon, but I'm wondering if
there's any opinion on what should be included. There are a few
interesting development efforts going on, such as encapsulation and
policy-branches, and the question is if we should wait for them to
become part of the main
On Wed, Feb 06, 2008 at 11:41:36AM +0100, Richard Levitte wrote:
I'm thinking of making a release pretty soon, but I'm wondering if
there's any opinion on what should be included. There are a few
interesting development efforts going on, such as encapsulation and
policy-branches, and the
Hi,
Nathaniel Smith wrote:
My opinion is that every time we catch ourselves thinking release
and wait for ___ in close proximity, we should smack ourselves and
go back to making the release. Remember the pathological spirals
*every* FOSS project used to get into back in the day, never
On Wed, 2008-02-06 at 11:41 +0100, Richard Levitte wrote:
Hello,
I'm thinking of making a release pretty soon, but I'm wondering if
there's any opinion on what should be included. There are a few
interesting development efforts going on, such as encapsulation and
policy-branches, and the
Hi,
Richard Levitte wrote:
Either way it goes, I wasn't considering waiting ENDLESSLY. I was
rather pondering if I should make a release this week (would be
friday) or next (would be that friday then).
I'd personally vote for a release this week. If Zack considers nvm.e.e
mature enough to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Markus Schiltknecht schreef:
| Hi,
|
| Richard Levitte wrote:
| Either way it goes, I wasn't considering waiting ENDLESSLY. I was
| rather pondering if I should make a release this week (would be
| friday) or next (would be that friday then).
|
|
In message [EMAIL PROTECTED] on Wed, 6 Feb 2008 11:52:38 +, Nathaniel
Smith [EMAIL PROTECTED] said:
njs My opinion is that every time we catch ourselves thinking
njs release and wait for ___ in close proximity, we should smack
njs ourselves and go back to making the release. Remember the
Hello Boris,
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
Hi,
Koen Kooi wrote:
Releases are cheap[1]
Not sure how much Richard and the downstream packet managers agree with
that, even given [1].
[1] Provided people keep NEWS and translations up to date without
Richard having to poke you ;)
Regards
Markus
On Wed, Feb 6, 2008 at 7:40 AM, Markus Schiltknecht [EMAIL PROTECTED] wrote:
Either way it goes, I wasn't considering waiting ENDLESSLY. I was
rather pondering if I should make a release this week (would be
friday) or next (would be that friday then).
I'd personally vote for a release
On Wed, 06 Feb 2008 15:27:22 +0200, Timothy Brownawell
[EMAIL PROTECTED] wrote:
On Wed, 2008-02-06 at 12:30 +0200, Boris wrote:
On Tue, 05 Feb 2008 19:30:28 +0200, Zack Weinberg [EMAIL PROTECTED]
wrote:
[...]Because this is a distributed VCS, we can't, ultimately, prevent
people from
On Wed, 06 Feb 2008 14:51:27 +0200, Markus Schiltknecht
[EMAIL PROTECTED] 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
On Wed, Feb 6, 2008 at 10:29 AM, Boris [EMAIL PROTECTED] wrote:
[...]Because this is a distributed VCS, we can't, ultimately, prevent
people from doing whatever they want to their own copy [...]
Even if you have a copy of the database the
database knows who the admininistrators
On Wed, Feb 06, 2008 at 10:43:37AM -0500, Zack Weinberg wrote:
We think that it'll be both friendlier and more secure if we allow
people to do whatever they want locally, but not force changes in
violation of policy on anyone else. It ends up working almost like
what you describe in
Markus Schiltknecht wrote:
Hi,
Koen Kooi wrote:
Releases are cheap[1]
Not sure how much Richard and the downstream packet managers agree with
that, even given [1].
Provided it continues to build with the same compiler and so on (which
wasn't so, for example, for AMD64 + gcc3 + 0.37 :-P)
On Wed, Feb 6, 2008 at 10:42 AM, Boris [EMAIL PROTECTED] wrote:
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.
What is the rationale for this requirement? My
On Wed, Feb 6, 2008 at 10:50 AM, Jack Lloyd [EMAIL PROTECTED] wrote:
Anyone can, in
their own database, substitute a permission set signed with their own
private key which lists their own public key as having administrative
rights. But everyone else's database ignores that change
Hi,
Zack Weinberg wrote:
On Wed, Feb 6, 2008 at 10:42 AM, Boris [EMAIL PROTECTED] wrote:
The problem is the co-worker shouldn't be allowed to check out the files
at all.
That's what I'm referring to with the partial checkout thing. It's
currently not possible with monotone. And it would
On Feb 6, 2008 7:42 AM, Boris [EMAIL PROTECTED] wrote:
On Wed, 06 Feb 2008 14:51:27 +0200, Markus Schiltknecht
[EMAIL PROTECTED] 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
On Wed, Feb 06, 2008 at 10:52:20AM -0500, Zack Weinberg wrote:
What is the rationale for this requirement? My knee-jerk reaction is
that this is ultimately impossible to enforce (untrusted dev A can go
over to trusted dev B and ask to be shown),
I think the key here is the use of trusted:
On Wed, 06 Feb 2008 17:43:37 +0200, Zack Weinberg [EMAIL PROTECTED] wrote:
[...]We think that it'll be both friendlier and more secure if we allow
people to do whatever they want locally, but not force changes in
violation of policy on anyone else. It ends up working almost like
Yes, that's
Hi,
Boris wrote:
Yes, that's fine. I want people to do what they want but only in
projects they are allowed to work on - which means projects they
received through their monotone database. Other projects (in my
database) they are not assigned to should not be transferred to their
database -
On Wed, 06 Feb 2008 18:33:29 +0200, Jack Lloyd [EMAIL PROTECTED] wrote:
On Wed, Feb 06, 2008 at 10:52:20AM -0500, Zack Weinberg wrote:
What is the rationale for this requirement? My knee-jerk reaction is
that this is ultimately impossible to enforce (untrusted dev A can go
over to trusted
Hi,
Jack Lloyd wrote:
So, here is a question. What is the (intended) smallest unit of access
control in Monotone? A file or set of files/certs? A branch? A
project? An entire database containing (potentially) multiple
projects? A server instance serving (potentially, I don't think it's
Markus Schiltknecht [EMAIL PROTECTED] writes:
[...]
I'd generally vote for files, even if that's still a long way to go.
That strikes me as impractical. How can I merge two revisions if I
can't see some of the changed files? If my local repository contains
the files, how convincing is it
On Wed, 06 Feb 2008 19:07:44 +0200, Markus Schiltknecht
[EMAIL PROTECTED] wrote:
[...]Use multiple projects and let your developers only sync to the
central
If you mean with multiple projects multiple databases - yes, that's the
only solution I can think of currently.
repository.
Hi,
Bruce Stephens wrote:
That strikes me as impractical. How can I merge two revisions if I
can't see some of the changed files?
You should be able to merge, as long as the revisions you are trying to
merge both point to the same revid for all invisible or disallowed
files. Otherwise, you
Hi,
Boris wrote:
On Wed, 06 Feb 2008 19:07:44 +0200, Markus Schiltknecht
[EMAIL PROTECTED] wrote:
[...]Use multiple projects and let your developers only sync to the
central
If you mean with multiple projects multiple databases - yes, that's the
only solution I can think of currently.
On Feb 6, 2008 5:32 PM, Bruce Stephens [EMAIL PROTECTED] wrote:
Markus Schiltknecht [EMAIL PROTECTED] writes:
[...]
I'd generally vote for files, even if that's still a long way to go.
That strikes me as impractical. How can I merge two revisions if I
can't see some of the changed files?
Markus Schiltknecht [EMAIL PROTECTED] writes:
Bruce Stephens wrote:
That strikes me as impractical. How can I merge two revisions if I
can't see some of the changed files?
You should be able to merge, as long as the revisions you are trying
to merge both point to the same revid for all
Hi,
Nuno Lucas wrote:
Policy branches aside, this is a feature it would be nice to have:
merge/propagate with path restrictions.
A simple (and common) use-case is propagating/merging changes made in
a sub-directory (possibly a library, like sqlite in monotone repo) to
another branch.
This
Hi,
Bruce Stephens wrote:
Hmm. So the manifest has a hash that points to something that says I
don't have permission to it (rather than to the text itself). I guess
I can imagine that working.
Uh.. the manifest has never included the text itself, AFAIR. And still
today, the revision data
Markus Schiltknecht [EMAIL PROTECTED] writes:
Bruce Stephens wrote:
Hmm. So the manifest has a hash that points to something that says I
don't have permission to it (rather than to the text itself). I guess
I can imagine that working.
Uh.. the manifest has never included the text itself,
Hi,
Bruce Stephens wrote:
Uh.. the manifest has never included the text itself, AFAIR. And still
today, the revision data references the file's contents by hash
exclusively. So do the rosters.
I know, I meant that the thing referenced by the hash would not be the
real contents (it would be
Markus Schiltknecht [EMAIL PROTECTED] writes:
Bruce Stephens wrote:
Uh.. the manifest has never included the text itself, AFAIR. And still
today, the revision data references the file's contents by hash
exclusively. So do the rosters.
I know, I meant that the thing referenced by the hash
Hi,
Bruce Stephens wrote:
I doubt that would be workable.
Yeah, that was where I'm in agreement with you.
I was suggesting deliberately keeping the hash the same, but allowing
the thing refered to by it to be something other than the contents.
(It would need to be something special,
On Feb 6, 2008 6:46 PM, Markus Schiltknecht [EMAIL PROTECTED] wrote:
Nuno Lucas wrote:
Policy branches aside, this is a feature it would be nice to have:
merge/propagate with path restrictions.
A simple (and common) use-case is propagating/merging changes made in
a sub-directory
On Wed, 2008-02-06 at 19:36 +0200, Boris wrote:
On Wed, 06 Feb 2008 19:07:44 +0200, Markus Schiltknecht
[...]Please keep in mind, that policy branches do not exist, yet. And
there are about as may ideas, what it should be, as monotone developers
are around here.
Ah, my
On Wed, 2008-02-06 at 17:29 +0200, Boris wrote:
On Wed, 06 Feb 2008 15:27:22 +0200, Timothy Brownawell
[EMAIL PROTECTED] wrote:
On Wed, 2008-02-06 at 12:30 +0200, Boris wrote:
On Tue, 05 Feb 2008 19:30:28 +0200, Zack Weinberg [EMAIL PROTECTED]
wrote:
[...]Because this is a
On Wed, 2008-02-06 at 19:46 +0100, Markus Schiltknecht wrote:
Hi,
Nuno Lucas wrote:
Policy branches aside, this is a feature it would be nice to have:
merge/propagate with path restrictions.
A simple (and common) use-case is propagating/merging changes made in
a sub-directory
On Wed, 2008-02-06 at 11:33 -0500, Jack Lloyd wrote:
source. An example that comes to mind is that a contractor at
Microsoft working on the kernel is not allowed to see, say, the source
for Office (or even other parts of the kernel beyond his immediate
purview). Is it good development
Markus Schiltknecht [EMAIL PROTECTED] writes:
Hi,
Stephen Leake wrote:
I don't see how to do this on a branch basis.
The syntax of ~/.monotone/write-permission only allows specifying
users, not branches.
Correct, sorry for the noise, I mixed things up.
How do I specify that abe is
Hi,
Nuno Lucas wrote:
What's the problem with that? It is an independent library so any
other changes in other files have no relation with the changes we made
in that directory (or other restricted path).
No problem with that. I just don't agree that partly unmerged revisions
are a good
47 matches
Mail list logo
