Thread (15 messages) flat view 15 messages, 7 authors, 2016-06-15

Re: [ANNOUNCE] Cogito-0.12

From: Brian Gerst <hidden>
Date: 2016-06-15 22:42:01

Petr Baudis wrote:
  Hello,

  I'm happy to announce the release of the 0.12 version of the Cogito
SCM-like layer over Linus' GIT tree history storage tool. Get it at

	http://www.kernel.org/pub/software/scm/cogito/

or cg-update if you have an older version cloned.

  I wanted to release it later with more cool features, but after all
releasing often is good and people will get to test things more, and
I wanted to make it possible for kernel.org to upgrade to newer RPM.
But it may not be as stable as I'd wish and may have some rough edges,
so be warned.

  This release contains the latest stuff from Linus, with all the
packing stuff and everything. Other things include heaps of bugfixes,
enhanced options parsing, ~/.cgrc support, cg-push, real cg-tag, and
plenty of smaller but nice stuff. And more to come in next days!

  About cg-push, it:

  (i) works only locally or over git+ssh branches

  (ii) the head updated on the other side must be 'master' too
	(high priority to fix)

  (iii) the head updated on the other side is re-created, thus losing
	all attributes (ownership, permissions)
	(high priority to fix)

  (iv) won't update the remote working tree if there is any associated
	with the repository - do cg-cancel to catch up, but that will
	lose any local changes you did (note that I plan to rename
	cg-cancel to cg-reset)

  Also, I've deprecated rsync, as I explained in another mail. Use
cg-branch-chg to change the branch URLs to some more sensible scheme -
most likely HTTP, or SSH if you want to push as well.
I really question removing rsync before HTTP pulls become more 
effecient.  I did a complete pull of cogito from kernel.org, and http 
took over 50 minutes to pull everything, while rsync was done in just 
over 1 minute.  I dared not even try to pull the full kernel at that speed.

I suspect that part of the problem is that the pull methods are doing a 
depth first search, so we can't request the next object until the 
current object is fully received and parsed.  Changing to a breadth 
first search would allow multiple requests in flight and asynchronous 
processing which should speed things up.  I am exploring using the 
curl_multi_* functions to do this, but this will require changes to 
common code in pull.c.

--
				Brian Gerst
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help