On Mon, 2006-08-07 at 08:13 -0700, Justin Patrin wrote:
> This is a good point. Directories are being treated the same way as
> files, e.g. you have to specify them when using restrictions in order
> to commit them. But if you specify a directory everything inside of it
> also gets selected. I'm n
On Fri, 2006-08-04 at 13:01 -0700, Eric Anderson wrote:
> You're probably running into the problem of monotone keeping the
> entire commit in memory. eddb7e59361efeb8d9300ba0ddd7483272565097
> from net.venge.monotone.experiment.performance fixes this.
Damn but this all sounds very familiar... Op
On Fri, 2006-08-04 at 22:50 +0200, Thomas Moschny wrote:
> On Friday 04 August 2006 22:25 Jonathan S. Shapiro wrote:
> > For example, the "mtn status" command gives status for
> > every file in the project. If this output was PWD-relative, you would
> > get thi
On Fri, 2006-08-04 at 22:33 +0200, Richard Levitte - VMS Whacker wrote:
> shap> USE CASE:
> shap>
> shap> The use case that I know best is the one for the EROS tree. Our
> shap> workspace tree has a basic directory structure, and within that there
> shap> are places where users can introduce thei
On Fri, 2006-08-04 at 14:47 -0500, Timothy Brownawell wrote:
> We have seen some slowness, yes. Our current thinking is to store our
> rosters as table rows.
Yes. This seems good, but it raises a question at the replication layer.
If the fundamental unit of replication at the sync layer is rows, y
On Fri, 2006-08-04 at 22:06 +0200, Thomas Moschny wrote:
> The confusing thing about this is that paths provided by the user on the
> command line always have to be relative to the current working directory,
> while the paths emitted as the result of mtn commands (i.e. presented to the
> user)
On Fri, 2006-08-04 at 15:01 -0500, Timothy Brownawell wrote:
> > Depending on the answer, would you consider a patch to add this behavior
> > or (if it already exists) clarify this part of the documentation?
>
> I can't speak for everyone, but I wouldn't object. We might want a way
> to override i
On Fri, 2006-08-04 at 20:55 +0100, Bruce Stephens wrote:
> "Jonathan S. Shapiro" <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > Also, the need to sync a 400 kbyte object in order to begin a
> > checkout is very disconcerting to users -- especially when you a
On Fri, 2006-08-04 at 14:52 -0500, Timothy Brownawell wrote:
> Paths given on the command line are relative to $PWD. Paths given in
> monotone's output are (mostly) relative to the project root.
This is the behavior in OpenCM as well.
___
Monotone-dev
On Fri, 2006-08-04 at 14:47 -0500, Timothy Brownawell wrote:
> Internally, we don't really use manifests (much) anymore. Instead we
> use "rosters", which are private manifest-plus-merge-metadata objects.
> We currently store them as plaintext, but have been considering
> storing them as sets of d
On Fri, 2006-08-04 at 21:44 +0200, Thomas Keller wrote:
> Hrm... indeed, never noticed that. Exists a bug already for this
> misbehaviour?
Since it isn't misbehavior, I hope not. :-)
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://li
On Fri, 2006-08-04 at 21:38 +0200, Koen Kooi wrote:
> - On 8/4/06, Koen Kooi <[EMAIL PROTECTED]> wrote:
> >>
> >> Try:
> >> [EMAIL PROTECTED]:~/OE/monotone/org.openembedded.dev/packages/e17$ mkdir
> >> baz
> >> [EMAIL PROTECTED]:~/OE/monotone/org.openembedded.dev/packages/e17$ cd baz/
> >> [EMAIL
On Fri, 2006-08-04 at 21:24 +0200, Koen Kooi wrote:
> Try:
>
> [EMAIL PROTECTED]:~/OE/monotone/org.openembedded.dev/packages/e17$ mkdir baz
> [EMAIL PROTECTED]:~/OE/monotone/org.openembedded.dev/packages/e17$ cd baz/
> [EMAIL PROTECTED]:~/OE/monotone/org.openembedded.dev/packages/e17/baz$ touch
If I understand the documents correctly, there are a whole lot of places
in the monotone schema that are very similar to things we did in OpenCM.
One of these bit us badly on scalability. I want to identify the issue,
explain how it bit us, and ask whether it has been a problem in
monotone. If not,
The manual seems to say that monotone takes the "one tree" approach --
there is a top (root) directory for the project, and everything under
that is assumed to be part of the project.
In the EROS and Coyotos projects, we have found that this structure
doesn't work for us. Several other OpenCM user
Monotone seems to have borrowed the .cvsignore idea directly
for .mtn-ignore. When we did this for OpenCM, we introduced a small,
backwards-compatible change that users really seem to like. I'ld like to
propose that Monotone adopt what we did. It's useful, backwards
compatible, simple to do, and I'
I'm Jonathan Shapiro, one of the OpenCM folks. Obviously I'm new to the
list.
Monotone and OpenCM share a bunch of ideas, and differ radically in a
bunch of others. From what I'm seeing, monotone looks like very good
work. Since OpenCM has stalled for lack of time, I'm exploring whether
we should
17 matches
Mail list logo
