bug-hurd
[Top][All Lists]
Advanced

[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

Hello!

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:
<http://lists.gnu.org/archive/html/bug-hurd/2008-08/msg00022.html>


> > 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
synch.

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.


Regards,
 Thomas

Attachment: signature.asc
Description: Digital signature


reply via email to

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