Mercurial Manager: A call to arms

[Tane Piper]

Hi again folks,

taking on board some of the comments I have received, I have thrown up
a wiki here (http://dev.digitalspaghetti.me.uk/) to start discussing
and documenting the application.

I've started looking at the layout of the application, and I have
refactored the code to start decoupling the application.  There is now
a core folder that will contain all core functionality required
(contexts, template tags, filters, plus openid support), then
application modules such as Project, Repo and Member.

On top of this, the app will then allow users to plug in any
application they want around the app, or to integrate the application
into their own software.

I've also looked at freehg.org's code, and it looks like using hgweb
within the application will be the best way to display repository data
from within the django views.  I'll be looking into this more.

Anyway, please feel free to throw up your comments and suggestions on the wiki

On Sat, Apr 12, 2008 at 11:02 AM, Tane Piper
<digitalspaghetti at googlemail.com> wrote:
> Hi Bryan,
>
>  Thanks for the feedback.  What I'm not trying to do is make a total
>  replacement for hgweb, but instead provide a way for setting up remote
>  repositories very easily, and promoting good source control use by
>  putting repos under projects, so it promotes proper branching.
>
>  I understand what your saying about the Wiki & issue tracker, but part
>  of this comes down to the bad design.  I DON'T want to get rid of
>  these features, however I want to decouple them more, and offer them
>  as additional applications that can easily be added into the core
>  application, however these can be put to one site for now so core
>  features can be worked on.  I want to start looking at making each
>  part a separate component, only having some core modules (Config,
>  Core, Project, Repo & Member) that make up the basic application.
>
>  By doing this, further down the line this will allow anyone who wants
>  to run a mercurial manager instance to install whatever components
>  they need, like a forum, blog, or even their own custom issue tracker.
>   I don't want to constrain users to how they want to run their site.
>
>
>
>
>  On Fri, Apr 11, 2008 at 9:09 PM, Bryan O'Sullivan <bos at serpentine.com> wrote:
>  > I'm afraid I think you're heading off in the wrong direction.  Actually,
>  >  it looks like you're trying to head in several wrong directions all at once.
>  >
>  >
>  >  > With the launch of github the other day, git is starting to race away
>  >  > from mercurial [...]
>  >
>  >  Cheap advice: don't stress over git.
>  >
>  >
>  >  > At the moment, the app is starting to get some critical features but
>  >  > due to bad design decisions early on,
>  >
>  >  Can you fill us in on these decisions and their consequences?
>  >
>  >
>  >  > - Basic issue tracker
>  >  > - Basic wiki
>  >
>  >  Not to put too fine a point on it, but these should be dropped immediately.
>  >
>  >  Focusing on a useful core component - decent hosting - is much more
>  >  important than trying to build yet another wiki and bug tracker.
>  >
>  >  > - Backup feature
>  >
>  >  Likewise.  "hg clone" is your free, prepackaged backup feature.
>  >
>  >
>  >  > - Display changeset information, including manifest, tags, branches
>  >  > and you can go back and forward through changeset history
>  >
>  >  You are duplicating hgweb?
>  >
>  >  If you have few resources, it's key to attend to a handful of things you
>  >  can do well.  Don't spread yourself out: you'll get nowhere.
>  >
>  >         <b
>  >
>
>
>
>
>
> --
>  Tane Piper
>  Blog - http://digitalspaghetti.me.uk
>  Skype: digitalspaghetti
>
>  This email is: [ ] blogable [ x ] ask first [ ] private
>



-- 
Tane Piper
Blog - http://digitalspaghetti.me.uk
Skype: digitalspaghetti

This email is: [ ] blogable [ x ] ask first [ ] private