Hello Nuno,
Nuno Lucas wrote:
The ideal (in an academic view) source code has the maximum
independence possible between source files, so one can achieve maximum
re-usability. So every source file can be thought as an internal
library (a black box) for the rest of the program.
It's when you grou
On Feb 10, 2008 10:57 PM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote:
> Nuno Lucas wrote:
> > In this case you could say they are modules, but it could be a single
> > file on the source tree, with no clear separation between it and other
> > source files. You can't have a branch per source file
On Feb 11, 2008 9:09 AM, Daniel THOMPSON <[EMAIL PROTECTED]> wrote:
> Nuno Lucas wrote:
> >>> Probably this will be solved when monotone gets a proper "cherry pick"
> >>> system. It would then be possible to "pluck" some group of revisions
> >>> (that could be restricted by path) and retain history
On Feb 9, 2008 11:47 AM, Bruce Stephens <[EMAIL PROTECTED]> wrote:
> "Nuno Lucas" <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > An extreme example of "cherry picking" is git bissect command. You
> > could have the some functionality on monotone if people could also
> > "unpluck" a changeset.
>
> git
Nuno Lucas wrote:
>>> Probably this will be solved when monotone gets a proper "cherry pick"
>>> system. It would then be possible to "pluck" some group of revisions
>>> (that could be restricted by path) and retain history.
>> I'm not exactly sure what you have in mind for being a "proper cherry
>
Hello Nuno,
Nuno Lucas wrote:
In this case you could say they are modules, but it could be a single
file on the source tree, with no clear separation between it and other
source files. You can't have a branch per source file (you could but
makes no sense).
You can commit different changes to a
On Feb 8, 2008 12:22 PM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote:
> Nuno Lucas wrote:
> Well, as long as no single commit spans several modules, you should
> probably use separate branches per module anyway.
In this case you could say they are modules, but it could be a single
file on the so
Hi,
Nuno Lucas wrote:
I see the problem now.
Seems like the simple way of solving it may be by introducing helper
revisions. But that could clutter the repository with no apparent
gain, aside more history.
OTOH, I somehow missed the path restriction option on "mtn pluck".
Maybe it wasn't there
On Feb 7, 2008 7:16 AM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote:
> > By the way, I don't see as this is any different than what is already
> > done by a 3-way merge with user editings. It's not the original
> > revision either.
>
> Well, the difference is, with a 3-way merge, you are saying:
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
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 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
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
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
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,
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,
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" == Markus Schiltknecht <[EMAIL PROTECTED]> writes:
Markus> With read-permissions and write-permissions, you can already
implement
Markus> some sort of a person <-> branches thing. Please check the manual
for
Markus> these things. Considering that most commercial projec
Hello Boris,
Boris wrote:
You are right. I need to clarify my requirements: I need to define
projects and assign people to them. People can do whatever they want in
their projects. However they must not get the files in the other
projects (which means they either aren't transferred or they are
Before I get into specific concerns of yours, I want to say up front
that this list talks about "policy branches" as if it were one thing,
but it's not; it's a whole cluster of features. We ultimately want to
support all of them, but we're not going to do all of them at once.
If I understand your
22 matches
Mail list logo
