[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ikiwiki fuckup...
Re: ikiwiki fuckup...
Mon, 18 Aug 2008 17:21:03 +0200
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
Description: Digital signature