[Top][All Lists]

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

Re: ikiwiki fuckup...

From: olafBuddenhagen
Subject: Re: ikiwiki fuckup...
Date: Mon, 18 Aug 2008 19:06:26 +0200
User-agent: Mutt/1.5.18 (2008-05-17)


On Mon, Aug 18, 2008 at 05:21:03PM +0200, Thomas Schwinge wrote:
> On Fri, Aug 15, 2008 at 01:44:44AM +0200, olafBuddenhagen@gmx.net
> wrote:

> > Now what about the promised Savannah backup? :-)
> Hmm?  I wrote about that two weeks ago:
> <http://lists.gnu.org/archive/html/bug-hurd/2008-08/msg00022.html>

Strange... It got totally lost from my memory :-(

Perhaps I got mislead by the web interface on Savannah pointing to a
(non-existant) hurd.git instead of hurd/wiki.git...

> > I still wonder though what the purpose of this internal/external
> > distinction is in the first place; and why there are no safeguards
> > against such situations...
> There are two distinct repositories as the web-interface's one indeed
> only is a clone of a dedicated master repository: ikiwiki can (and
> hast to) freely scribble on that one.

Why does it need to scribble over it?...

Ah well, this is really a question for the ikiwiki developer, and rather
off-topic here...

> The problem arises, as ikiwiki [A] permits to record changes in the
> web-interface's repository even if the master one isn't reachable.
> This usually shouldn't hurd -- at least as long as people don't
> (unknowingly) create conflicting commits, as all the other ones will
> simply be merged the next time the two repositories are brought back
> in synch.
> Disallowing [A] would ``fix'' this problem.

That would be a rather radical solution...

> But also, perhaps ikiwiki should fail more gracefully if there are
> conflicting changes, and not bail out as it did for us.

I'm not sure how else it should behave.

> I can't think of any simple safe-guard to apply here.

One possible approach would be to have a hook in the external
repository, checking before every external push that it's in sync with
the internal one...

Of course, this would still be problematic, when the internal repository
is not reachable...


reply via email to

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