Mercurial on AppEngine

[jmuk]

2008/12/4 Benoit Boissinot <bboissin at gmail.com>

> On Wed, Dec 3, 2008 at 5:13 PM, jmuk <jun.mukai at gmail.com> wrote:
> > Hello,
> >
> > I think definitely some guys already tried similar things, but I cannot
> find
> > them now, so...
> > I am pleased to announce that I "ported" Mercurial into Google AppEngine.
> > http://hg-repos.appspot.com/
>
> It looks interesting. Thanks for posting it.
>

I am happy to read this.  Thanks.


> > caution: Google AppEngine has many restrictions onto the applications
> like
> > bandwidth, cpu time, data storage size or so on.
> > Because of those restrictions, huge size of repository (such like hg
> itself)
> > is not suitable to AppEngine.  You cannot push/pull 6000 changes at once
> :(
> >
> Can you explain what the problem is?
>

Sure.

Actually, AppEngine has quota for bandwidth (MB/day), CPU time (CPU cycles
per day),
and total data storage.  And, you know, accessing database consumes much CPU
time.
In addition, application should return its response within a few seconds.
The problem is, pushing 6000 changes consumes tons of CPU time at once
(actually
it takes more than minutes), so AppEngine framework misdetects processing
changes as
an attack to vulnerability to my application because CPU load goes too high.
That is the reason.  We can avoid them by splitting changes manually by -r
flag.

In addition, total data storage quota is only 500MB, and my app requires
more storage
than usual mercurial in order to reduce CPU cycle.  I think we can still
store hg itself,
but pushing those changes without exceeding cpu cycle quota is really time
consuming.
In my local environment, I can store more than 3000 changes from hg-stable.

Anyway, if you want to start a repository, it might be ok to grow the
repository to tons of changes.


 regards,
Jun Mukai


>
> > caution2:  This must have bugs and lacks some functionalities.  For
> example,
> > I didn't implement branches at all.  If you find bugs and loss of
> functions,
> > please let me know.
>
> I think a solution that would be accepted upstream would be to add a python
> version of each C module. I see you already did part of that.
>
> regards,
>
> Benoit
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20081205/ae276e0e/attachment.htm