Re: sawfish development tools

[Scott Scriven <sawfish-list toykeeper net>]

* Janek Kozicki <janek_listy wp pl> wrote:
> just a side note - launchpad is hosted by canonical - the 
> people who made ubuntu. AFAIK the CMS used on launchpad is 
> closed source, but maybe it has changed recently?

The base (Zope) is open, and many of the modules are open, but 
some of the core in-between in still closed.  I know they're 
working on opening the rest, but it's coming in small pieces.

On the other hand, ever tried to get the source for sourceforge?  
It's completely proprietary, and the terms of use require 
granting SF's company a permanent license to use your work in 
pretty much any way they like.

> > There seem to be sawfish add-ons all over...  could we merge 
> > these into a "contrib" area in the sawfish repository
> 
> that's an interesting idea.

Personally, I'd like to put my tabbed windowing stuff into the 
sawfish repository, though not necessarily into the core of the 
source tree.  It's not really mature enough to be included by 
default.

And, I'd like to put other people's extra stuff into the same 
place, though it'll take a while to find and organize everything.

> Yeah, however it evolves, I think that we should stay with 
> patch voting system on the wiki.

Yup.  I really like having code review and voting.  The details 
aren't so important, but new code needs to be looked over before 
it's accepted.

> Just the patches will not be copy/pasted in the page,

Actually, merge bundles can be copied through a wiki without 
losing any data.  It gets encoded in plain text, like base64 
email attachments.  Of course, merging from a branch works too, 
but it's just as easy to merge from a copy/pasted bundle.

> there was one thing which was disturbing for me about BZR. 
> Unless explicitly instructed it kept insisting on downloading 
> whole repository, all revisions.

All DVCS systems are this way.  You need a local copy of the 
repository before you can really do anything with it.

However, I hear that one of the core bzr developers is working on 
a "shallow branches" feature to change this.  It would let you 
pick an arbitrary starting point in history, and download only 
the changes since then.

> We wanted to move to BZR with YADE which is quite a big 
> project. Downloading YADE with all its history took quite a 
> long time, so finally that's why we decided to stay with SVN.  
> But sawfish is small in size, so that shouldn't be a problem.

Before you mentioned this, actually, I did some tests...  I 
wanted to find out how git and bzr handle sawfish's complete 
history, so I converted the svn repo to both git and bzr.  What I 
found was roughly what I expected.  The short version is:

  - Git is (usually) quite a bit faster, and uses much less RAM.  
    Gitk, while awesome, was the exception.  It was surprisingly 
    slow, and failed at unicode.

  - Bzr used less space.  (and, much less space when using 
    lightweight checkouts or shared repositories)

  - Converting history from upstream took at least an hour.  That 
    may seem long, but remember it's grabbing ~30,000 files and 
    ~4,000 versions over http, and that's got to be at least 
    100,000 HTTP requests (or, at least 27 per second).

  - Most of sawfish-svn's files are in branches/ or tags/ .  This 
    would need to be fixed for a "final" conversion because, 
    while copies are cheap in svn, they don't work the same way 
    elsewhere.

... and the long version is below:

To convert sawfish's svn repo, run...

  Git:

    apt-get install git-svn
    git-svn clone http://svn.gnome.org/svn/sawfish/ sawfish.git

    This took about an hour, and 80 MiB RAM.
    Making a new copy of the branch over 802.11g took 4 minutes.
    I ran gitk twice (once to get things into RAM)...  Loading 
    gitk took 68 seconds and 82 MiB RAM, the second time.
    'git status' took 1.2 - 1.4 seconds after caching.
    'git diff' took 9.3s the first time, then 0.2s afterward.

  Bzr:

    apt-get install bzr-svn
    bzr branch http://svn.gnome.org/svn/sawfish/ sawfish.bzr

    This took about two hours, and 500+ MiB RAM.  I think the 
    slowdown was due to memory swap on my notebook.
    Making a new copy of the branch over 802.11g took 11 minutes.
    (a trunk-only copy took 1m45s)
    Loading 'bzr vis' took 28 seconds and 233 MiB RAM, the second time.
    'bzr status' took 1.9 - 2.2 seconds after caching.
    'bzr diff' took 18.3s the first time, and 2.0s afterward.

After conversion, sawfish (complete) had:

      4226 revisions (4226 in the main branch)
     100.4 MiB of history (bzr)
     178.3 MiB of history (git)
     29960 files and 2028 directories in the working tree
           (599 in trunk, 1462 in branches, 27899 in tags)

With only trunk/, sawfish had:

      3949 revisions
      18.6 MiB history (bzr)
       598 files and 39 directories in the working tree

By comparison, the main branch of bzr has:

     18055 revisions (3506 in the main branch)
      80.4 MiB of history
       868 files and 71 directories in the working tree

I found that bzr commands were ~10 times faster in the bzr repo 
than in the sawfish repo.  This tells me that the size of the 
HEAD revision affects speed more than the depth of history.  So, 
after trimming branches/ and tags/, the average command execution 
time should be around 0.2s to 0.5s.


Anyway, that was probably way more detail than necessary.  I just 
like to play with SCM tools, and this is a fun case to examine.  
:)


-- Scott