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 thing
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 th
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 pro
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-d
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:
> >>
> >> > [...]B
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 u
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-dir
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, otherwis
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
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 som
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 tex
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 re
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 w
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 fo
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 ch
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.
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
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. Prev
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 t
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 d
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
supported
Hi,
Justin Patrin wrote:
I think what you're describing is a false sense of security. If the
"central repository" enforces that certain people can pull certain
files an certain people can't then that doesn't stop someone who has
access sending the files over to someone who doesn't have access.
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 - n
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
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:
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 woul
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
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 cha
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
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.3
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 pract
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 a
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 wil
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 fr
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
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 doing whatever they want to their own copy of the
>
> It might be possible if
Koen Kooi <[EMAIL PROTECTED]> writes:
[...]
> Releases are cheap[1], there's nothing against a release this week and a
> release with mvm.e.e a short while after that.
>
> regards,
>
> Koen
>
> [1] Provided people keep NEWS and translations up to date without
> Richard having to poke you ;)
Rele
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
-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).
|
|
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 administr
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 go
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. Remem
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
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
relea
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 q
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 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 i
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 branc
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.
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 branch
50 matches
Mail list logo
