In D6424#172094, @dachary wrote:

I don't think we should be storing fields defined as size_t on disk, as I believe that's architecture-dependent: I see that you have defined and use ntohq / htonq to, if I understand correctly, make sure that the endianness of the data stored on disk is always in network byte order (although currently we're just always swapping the byte orders, AFAICT). If we end up using an architecture with a 32 (or 128) bit size_t, or even rarer, a big endian architecture, we'll have a bad time.

I think we should:

store explicit uint64_t values on disk, with a specified byte order.

Done.

use off_t instead of size_t on the C side, for types that store file offsets (which should be a signed 64 bits value when compiled with -D_FILE_OFFSET_BITS=64, even on 32 bits systems). Unfortunately that means wasting a bit on offset storage, but I think we can live with that.

I'm not sure what would be the upside so I kept it as u_int64_t. Do you have a specific scenario in mind where it would create a problem?

Build is green

Build is green

Update commit msg

Use empty string as author instead of None, it's actually unclear how to make the model handle None authors with non-None dates

abandonning this, as there isn't a good way to serialize manifests with a date but no author

abandonning this, as there isn't a good way to serialize manifests with a date but no author

Moving towards event notifications and stream processing instead of polling sounds worthwhile, before the amount of polling becomes more important than managing the event notification mechanism. For the two systems you've mentioned, I think we're really, really far away from that, but it's still worth considering a way to do event-driven notifications properly, so we don't have to rush it through.

Build is green

Build was aborted

Build is green

Build has FAILED

Build is green

makes sense

Can you add a test that the manifest renders properly (with the date) in that case?

rebase

rebase

rebase

a couple of remarks inline.

Build has FAILED

Build is green

changes suggested by vlorentz

Build is green

Build is green

rebased patch

Build is green

rebased patch

rebase

Build is green

rebased patch

Build is green

rebased patch

Thanks!

Looks good

What's missing, provider_url and domain:

db is almost ready:

As of D6623 the CVS loader is able to convert GNU dino correctly over both rsync and pserver access.

Build is green

Wrap the remove instruction in case failure to remove happens.

Build is green

assert self.cvsroot_path instead of casting and squash all changes

Build is green

Update