Fri, 16 Apr 2010 01:58:14 +0200 merge with stable
Benoit Boissinot <benoit.boissinot@ens-lyon.org> [Fri, 16 Apr 2010 01:58:14 +0200] rev 10929
merge with stable
Fri, 16 Apr 2010 01:57:53 +0200 test-git-import: better testing, check nodeids stable
Benoit Boissinot <benoit.boissinot@ens-lyon.org> [Fri, 16 Apr 2010 01:57:53 +0200] rev 10928
test-git-import: better testing, check nodeids
Fri, 16 Apr 2010 01:57:32 +0200 context: fix bug introduced in fb89cd21a7a0, path should be used stable
Benoit Boissinot <benoit.boissinot@ens-lyon.org> [Fri, 16 Apr 2010 01:57:32 +0200] rev 10927
context: fix bug introduced in fb89cd21a7a0, path should be used
Thu, 15 Apr 2010 22:34:26 +0200 merge with stable
Sune Foldager <cryo@cyanite.org> [Thu, 15 Apr 2010 22:34:26 +0200] rev 10926
merge with stable
Thu, 15 Apr 2010 21:59:21 +0200 prepush: rewrite most of the code from scratch stable
Sune Foldager <cryo@cyanite.org> [Thu, 15 Apr 2010 21:59:21 +0200] rev 10925
prepush: rewrite most of the code from scratch For servers with branchmap support, the algorithm now works as follows: 1. A list of branches in outgoing changesets is created. 2. Using the remote branchmap, a check for new branches is performed. 3. A map (from branch to head list) of locally known remote heads before the push is created, and one which, after step 4, will contain the locally known remote heads after the push. 4. The post-push head map is updated with the outgoing changesets, using the branch cache update mechanism. 5. A check for new heads is performed, by comparing the length of the head list before and after push, for each branch. If there are new heads, an error depending on whether or not there are incoming changes on the branch, is returned. 6. If the push is allowed, a warning is written if there are incoming changes on any branches involved in the push. For old servers, an algorithm similar to step 4-6 above is used to check for new topological heads only. Two bugs are also fixed: 1. Sometimes you would be allowed to push new branch heads without --force. A test for this case was added. 2. You would get the "note: unsynced remote changes!" warning if there were any incoming changesets, even if they were on unrelated branches.
Thu, 15 Apr 2010 20:25:26 +0200 merge with stable
Benoit Boissinot <benoit.boissinot@ens-lyon.org> [Thu, 15 Apr 2010 20:25:26 +0200] rev 10924
merge with stable
Thu, 15 Apr 2010 20:25:07 +0200 run-tests.py: can't remove from os.environ on solaris stable
Benoit Boissinot <benoit.boissinot@ens-lyon.org> [Thu, 15 Apr 2010 20:25:07 +0200] rev 10923
run-tests.py: can't remove from os.environ on solaris
Thu, 15 Apr 2010 19:03:03 +0200 merge with stable
Benoit Boissinot <benoit.boissinot@ens-lyon.org> [Thu, 15 Apr 2010 19:03:03 +0200] rev 10922
merge with stable
Thu, 15 Apr 2010 18:08:48 +0200 workingctx: correctly compute the flag for noexec filesystems+merge stable
Benoit Boissinot <benoit.boissinot@ens-lyon.org> [Thu, 15 Apr 2010 18:08:48 +0200] rev 10921
workingctx: correctly compute the flag for noexec filesystems+merge This bug happens if the filesystem doesn't support exec-bit, during merges, for example in 24ed7a541f23 on the hg repo. If f is not in p1, but is in p2 and has the x-bit in p2, since the dirstate is based on p1, and the FS doesn't support the exec-bit, the dirstate can't "guess" the right bit. We instead fix it in workingcontext.flags()/manifest.
Thu, 15 Apr 2010 17:25:37 +0200 localrepo: simplify _updatebranchcache slightly
Sune Foldager <cryo@cyanite.org> [Thu, 15 Apr 2010 17:25:37 +0200] rev 10920
localrepo: simplify _updatebranchcache slightly
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip