monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Db row size, pushing a new project to the depot, et


From: graydon hoare
Subject: Re: [Monotone-devel] Db row size, pushing a new project to the depot, etc.
Date: 12 Nov 2003 10:12:43 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Kevin Smith <address@hidden> writes:

> I finally subscribed to the list today, so I can't directly reply to
> some of the interesting messages that I have seen on the archives. I'm
> still optimistic that monotone will meet my needs, so I'm here to try
> to confirm that.

I sure hope so :)

> The db row limit was probably triggered by an attempt to check in a 4
> megabyte file. It wasn't intentional on my part. When I added my
> directory, monotone chose to include my project target .so shared
> library file, instead of ignoring it.

ah yes, ok. I've just extended the standard ignore_file hook in my
working copy to skip .so, .lo, .la, and .a files too, in addition to
.o (which it already did).

> In my case, it wasn't a CVS import that triggered it. I had fetched
> monotone from your depot, and wanted to start my own branch depot. I
> assume the addtree command will do the right thing in my case as
> well.

depends on what you mean by the "right thing". recall that the head
has the same SHA1 whether or not its history is present in your depot,
so there's really no need to queue the whole history. 

if you just commit a new version to your database and have it set to
queue that branch (net.venge.monotone) for *your* depot, monotone will
see that your depot has no predecessor versions at all and queue a
single, full-data (not deltas) copy of your head.  subsequent commits
will queue deltas.

addtree is more thorough, and really a special case for importing a
CVS tree: it queues the *entire history* of all the heads of your
branch, not just a head itself.

> Has anyone else raised concern about the depot database location?
> Without thinking it through thoroughly, it seems odd to require write
> rights in a cgi-bin directory.

I agree, it feels a bit weird. you don't need to make the directory
writable though, just a file in it. if you have a better suggestion
about confining a writing process on a CGI server, I'd like to know
it. I haven't done a great deal of CGI work, so don't know the
current consensus on this.

> I think that's all for now. I'll probably start trying to build
> monotone on my system so I can play with the new commands before the
> next release. Wish me luck...

great, good luck!

-graydon





reply via email to

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