[Top][All Lists]

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

Re: ikiwiki fuckup...

From: Thomas Schwinge
Subject: Re: ikiwiki fuckup...
Date: Mon, 18 Aug 2008 17:21:03 +0200
User-agent: Mutt/1.5.11


On Fri, Aug 15, 2008 at 01:44:44AM +0200, olafBuddenhagen@gmx.net wrote:
> On Wed, Aug 13, 2008 at 04:04:51PM +0200, Thomas Schwinge wrote:
> > On Wed, Aug 13, 2008 at 08:54:40AM +0200, olafBuddenhagen@gmx.net
> > wrote:
> > > The tricky part is that these changes were originally pushed to the
> > > github backup
> > 
> > Someone please tell me and the others how to get access to that one?

He sent instructions to web-hurd in the mean time.

> > I can't seem to find an email or wiki page telling about this.
> Indeed there is none... Though I'm not sure this is a problem,
> considering that it was only meant as a temporary measure for the
> specific needs of GSoC?

OK, true.  I (or someone else, of course) should add some text about the
Savannah one, though.

> Now what about the promised Savannah backup? :-)

Hmm?  I wrote about that two weeks ago:

> > This is what happened, I think.  flubber was down.  Someone did a
> > commit for `community/scolobb.mdwn' in the web-interface.  This change
> > was recorded in the web-interfaces's working copy, but obviously not
> > pushed to the flubber master copy, it being unreachable.  In parallel,
> > someone did push a commit for `community/scolobb.mdwn' to the flubber
> > master copy, when it was available again.  When doing that, this
> > change was automatically tried to be pushed to the web-interface's
> > working copy, creating a conflict in there.  Apparently ikiwiki was
> > not able to resort to some sane state (how would it, nevertheless).
> Yeah, I understood it as well now that it's fixed again, and seeing that
> there were several web commits that didn't show up in the external
> repository before...
> 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.

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

Disallowing [A] would ``fix'' this problem.  But also, perhaps ikiwiki
should fail more gracefully if there are conflicting changes, and not
bail out as it did for us.  I can't think of any simple safe-guard to
apply here.


Attachment: signature.asc
Description: Digital signature

reply via email to

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