All looks good to me.  A strange thought in my mind was that we should have a
global state in which we can state if we preserve previous messages and then
simply setting a new source or context causes the old ones to be preserved.  To
be honest I find set_as_previous() a strange construct.  But this is just a
thought.  I'm happy with the patch as it is and recommend that it be applied.

http://zuza.appspot.com/62/diff/21/5
File translate/storage/base.py (right):

http://zuza.appspot.com/62/diff/21/5#newcode305
Line 305: return self.prev_source
Shouldn't the decorators be here for prev_source?

http://zuza.appspot.com/62/diff/21/7
File translate/storage/cpo.py (right):

http://zuza.appspot.com/62/diff/21/7#newcode137
Line 137: gpo.po_message_prev_msgid.restype = STRING
I assume this should be previous msgctxt?  I know we are limiting this msgid and
msgid_plural.  But this would to me indicate our test coverage isn't complete.

http://zuza.appspot.com/62/diff/21/7#newcode190
Line 190: def setprev_context(self, msgid_context):
Can we avoid references to msgid but stick to generic naming i.e. simply
'context' would be fine

http://zuza.appspot.com/62/diff/21/7#newcode250
Line 250: self.prev_context = gpo.po_message_msgctxt(self._gpo_message)
Shouldn't this use an accesors like self.context to retrieve the context? 
Although I think that might create problems in that we currently also include
KDE style comments.  If so ignore this comment :)

http://zuza.appspot.com/62/diff/21/6
File translate/storage/test_base.py (right):

http://zuza.appspot.com/62/diff/21/6#newcode152
Line 152: assert unit.prev_source == "Test"
I would also test here for fuzziness since you do set the unit as fuzzy here
don't you?

http://zuza.appspot.com/62/diff/21/8
File translate/storage/test_cpo.py (right):

http://zuza.appspot.com/62/diff/21/8#newcode93
Line 93: assert isinstance(unit.prev_source, multistring)
Surely if we've removed the previous source we should have no entry?  Or is this
dealing with the special case that Friedel mentioned of sourceless messages?

http://zuza.appspot.com/62/diff/21/8#newcode122
Line 122: unit.msgid_plural = ["Tests %d"]
I'd rather see you set this through .source rather then msgid_plural

http://zuza.appspot.com/62/diff/21/5
File translate/storage/base.py (right):

http://zuza.appspot.com/62/diff/21/5#newcode305
Line 305: return self.prev_source
On 2008/07/17 12:59:27, dwaynebailey wrote:
> Shouldn't the decorators be here for prev_source?

Looking now, I think it should not have variables, just properties and empty
function bodies.
A side effect is that all the tests will be lost, since there will be nothing to
be tested. I'll wait for you reply, but I think it is the right way.

http://zuza.appspot.com/62/diff/21/7
File translate/storage/cpo.py (right):

http://zuza.appspot.com/62/diff/21/7#newcode137
Line 137: gpo.po_message_prev_msgid.restype = STRING
On 2008/07/17 12:59:27, dwaynebailey wrote:
> I assume this should be previous msgctxt?  I know we are limiting this msgid
and
> msgid_plural.  But this would to me indicate our test coverage isn't complete.

Oops, sorry. I did not noted that all the prev_* was already in there.

http://zuza.appspot.com/62/diff/21/7#newcode250
Line 250: self.prev_context = gpo.po_message_msgctxt(self._gpo_message)
On 2008/07/17 12:59:27, dwaynebailey wrote:
> Shouldn't this use an accesors like self.context to retrieve the context? 
> Although I think that might create problems in that we currently also include
> KDE style comments.  If so ignore this comment :)

I'll improve the comment above, but that was about the KDE style comments.

http://zuza.appspot.com/62/diff/21/8
File translate/storage/test_cpo.py (right):

http://zuza.appspot.com/62/diff/21/8#newcode93
Line 93: assert isinstance(unit.prev_source, multistring)
On 2008/07/17 12:59:27, dwaynebailey wrote:
> Surely if we've removed the previous source we should have no entry?  Or is
this
> dealing with the special case that Friedel mentioned of sourceless messages?

Hmm, I think it is not right. The source should not be affected by the previous
source (and so, we can't set a previous message for a sourceless unit).

On 2008/07/17 12:59:27, dwaynebailey wrote:
> All looks good to me.  A strange thought in my mind was that we should have a
> global state in which we can state if we preserve previous messages and then
> simply setting a new source or context causes the old ones to be preserved. 
To
> be honest I find set_as_previous() a strange construct.  But this is just a
> thought.  I'm happy with the patch as it is and recommend that it be applied.
> 

Yes. I think the unit-state will be very nice, but what do you think about we do
this inside a context ? (where there will have a use case of that)
The set_as_previous is just a sugar and came from when I was coding pot2po.py.
Maybe we should also remove it from this patch ?