monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] cvssync freeze


From: Christof Petig
Subject: Re: [Monotone-devel] cvssync freeze
Date: Tue, 20 Mar 2007 03:20:22 +0100
User-agent: Thunderbird 1.5.0.10 (X11/20070307)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

William Uther schrieb:
> Hi all,
> 
>   Again, this is probably most relevant to Christof Petig... I've just
> committed a test to the n.v.m.cvssync.refactor branch that causes a
> freeze in mtn_cvs pull.  The test is skipped just before the line that
> freezes.
> 
>   I've traced the problem back to mtn_automate::get_sync_info().  I
> generate a revision in mtn that has cvs: attributes, as well as a cert
> with sync info.  The cert appears to only contain cvs revision info for
> some of the files.  This manifests itself in cvs_repository::update()
> during a pull because the 'last' variable, that should contain the last
> cvs revision we synced with, is empty.  That then causes the
> "Inconsistency" on line 450 to show up.  That in turn fails an invariant
> which when thrown doesn't close all the various pipes correctly and
> leads to the freeze.
> 
>   So there are at least two problems here:
> 
>   i) Either mtn_automate::get_sync_info() should be falling back to file
> attributes when the cert doesn't contain the info it needs, or
>      Whatever writes the sync info into the cert needs to add sync info
> for all files in the revision.  (I suspect the first option here is
> better - it is backwards compatible with people who have already hit
> this problem, and it is more space efficient.)

I did not hit this problem, yet. Of course I prefer translucent or delta
changes.

> 
> and,
> 
>   ii) Failing an invariant should cause a clean windup, not a freeze
> where the child and parent process are each waiting on the other.

Of course. I just did not get around to investigate why invariance
failure is not handled correctly. The error is most likely in
mtn_automate.cc (client failure) or mtn_cvs.cc (program failure).

  Yours
     Christof

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF/0TXng+R+0ucfO0RAsHlAKDTPFfJLqsBsK5jnIe83QfShOK/XQCffk2O
aezKHbEcTEG40l83IAT4pA8=
=j9XC
-----END PGP SIGNATURE-----





reply via email to

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