Subject: [Tools-discuss] wiki-trac

From: "David Harrington" <[email-masked]>
Date: Mon, 13 Sep 2010 14:10:08 -0400

Hi,

Can we get some sort of SCCS lock capability on wiki-trac?
I just entered a BOF Request, which was rather slow and time-consuming
given the arcane formatting we use, and the difficulty of cutting and
pasting due to the way the cursor keeps repositioning the page while
you edit.
And somebody went in while I was previewing my changes, did an edit,
and I lost all my work.
I cannot tell when somebody else is editing, so I don't know when it
is safe to go back and do my edits again, so that I don't interrupt
their editing session.

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 16 Sep 2010 12:52:25 +0200

Hi David,

> And somebody went in while I was previewing my changes, did an edit,

Ouch.  But maybe not necessary, see below...

> is safe to go back and do my edits again, so that I don't interrupt

The handling already implemented in Trac is to 1) keep the edited
text in a text box in the view which tells you that the page has
been modified by somebody else, so you can copy it out and then fix
things in a new edit, and 2) at the bottom of the page, provide
'Merge changes' button which you can use to merge in your changes to
the modified page.  I think this is a reasonable handling?

Best,

	Henrik

---

From: "David Harrington" <[email-masked]>
Date: Thu, 16 Sep 2010 10:49:48 -0400

Hi Henrik,

Well, I saw the merge button, and I am used to CVS merge handling.
But I have no experience with Trac merge handling, and bluntly I
didn't trust it because I lacked experience with it.
If I had done the merge it would have occurred while somebody else was
apparently actively editing the same page. Given that the merge is
calculated based on a snapshot of the page at the time of the merge,
if it is a moving target, I'm not sure how well the merge would work.

I did actually cut and paste my work into a file so I didn't lose it.
But I could not tell when somebody else was editing, so I could not
tell when it was safe for me to re-submit without causing a merge
problem. (and I think the edits being done did not overlap with mine,
which I think would have been fine with a CVS system).

A little indicator that somebody else was actively editing the page
would have been wonderful.

But, given the frequency that this problem occurs, it certainly is not
one of the higher priority items.

Thanks,
dbh

> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email-masked]] 
> Sent: Thursday, September 16, 2010 6:52 AM
> To: David Harrington
> Cc: [email-masked]
> Subject: Re: [Tools-discuss] wiki-trac
> 
> Hi David,
> 
> The handling already implemented in Trac is to 1) keep the 
> edited text in a text box in the view which tells you that 
> the page has been modified by somebody else, so you can copy 
> it out and then fix things in a new edit, and 2) at the 
> bottom of the page, provide 'Merge changes' button which you 
> can use to merge in your changes to the modified page.  I 
> think this is a reasonable handling?
> 
> 
> Best,
> 
> 	Henrik
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 16 Sep 2010 17:27:48 +0200

Hi David,

> didn't trust it because I lacked experience with it.

Ah, well.  The only way to get experience is to try it.  Trac maintains
all back revisions, so it's easy enough to revert to an earlier version
if the merge proves catastrophic.

> apparently actively editing the same page.

Not necessarily so; you received the conflict warning because someone
else had completed an edit meanwhile.  If you had done your merge, and
they had continued to work on another edit, they would have received
a conflict message and merge offer in turn, which should also have turned
out well if you hadn't been editing the same piece of text...

> Given that the merge is

The merge is between the new version and the most recently committed
version; I think it should be just fine as long as the edits don't
overlap.

> I did actually cut and paste my work into a file so I didn't lose it.

Ah.  Good.

> which I think would have been fine with a CVS system).

And the same should be the case here.

> would have been wonderful.

But that would also require everybody to tell the system when they
abandon an edit (which not everybody are going to do) or rely on a
reasonable timeout, which would let you sit and wait for maybe 5 or
15 minutes before you could submit your edit.  I think the merge
approach is a rather good solution, and as mentioned above, the ability
to revert to earlier versions of the page makes sure that no merge
can be catastrophic.

> one of the higher priority items.

Also true.

Best,

	Henrik