More Subversion branch progress

meta = {'category': bazaar, 'date': Sun 16 April 2006}

After some more work on the ‘svn’ plugin, I am now able to do proper lightweight checkouts (including file contents) and run ‘bzr log’ or ‘bzr info’ on the working tree:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

charis:~/bzr/svn% bzr checkout --lightweight \\

          svn://svn.samba.org/smb-build/trunk smb-build
charis:~/bzr/svn% bzr info smb-build
Location:
       checkout root: /home/jelmer/bzr/svn/smb-build/
  checkout of branch: svn://svn.samba.org/smb-build/trunk

Format:
       control: Meta directory format 1
  working tree: Working tree format 3
        branch: Subversion Smart Server
    repository: Subversion Smart Server

In the working tree:
        16 unchanged
       117 modified
         0 added
         0 removed
         0 renamed
         0 unknown
         0 ignored
        16 versioned subdirectories

Branch history:
        30 revisions
       296 days old
   first revision: Fri 2005-06-24 11:24:47 +0000
  latest revision: Sun 2006-03-19 01:39:05 +0000
charis:~/bzr/svn% bzr log smb-build
------------------------------------------------------------
revno: 30
committer: jelmer
timestamp: Sun 2006-03-19 01:39:05 +0000
message:
  test double target
------------------------------------------------------------
revno: 29
committer: jelmer
timestamp: Sat 2006-03-18 23:56:09 +0000
message:
  Test whether a variable in the include file is supported
------------------------------------------------------------
revno: 28
committer: jelmer
timestamp: Sat 2006-03-18 23:10:09 +0000
message:
  Check ::
------------------------------------------------------------
revno: 27
committer: jelmer
timestamp: Sat 2006-03-18 23:01:55 +0000
message:
  Test whether include in make works
------------------------------------------------------------
revno: 26
committer: tpot
timestamp: Tue 2005-08-30 01:33:10 +0000
message:
  Fix the build.
------------------------------------------------------------
revno: 25
committer: tpot
timestamp: Tue 2005-08-30 01:23:44 +0000
message:
  Break the build.
------------------------------------------------------------
[...]

comments.

lightweight checkouts of SVN branches working

meta = {'category': bazaar, 'date': Sat 15 April 2006}

After a couple of hours hard work today, I finally got “lightweight” checkouts of Subversion branches in Bazaar working! I can now run

1

bzr checkout --lightweight svn://svn.samba.org/samba/trunk samba-trunk

and then end up with a proper Samba tree. Unfortunately, the size of all the files is still 0 at the moment, but that should be fixed soon.

Hopefully, this is the next step towards using bzr as a svk replacement.

Oddly enough, I have been contributing to Subversion as I hit a few problems in their Python bindings.

comments.

bzr speeding up Bitlbee development?

meta = {'category': bazaar, 'date': Wed 14 December 2005}

Now that we’ve switched to a version control system for Bitlbee, the development activity is suddenly reviving. The fact that 1.0 has now been released was certainly also a reason for the large number of commits in the past weeks, as previously we were mainly aiming at improving the stability of Bitlbee.

Some of the things that have been merged into the main tree over the past week or so are:

• groupchat support in oscar by Nelson Elhage
• typing notification improvements by f0rked
• new storage abstraction layer by me
• support for plugins by me

and lots of smaller improvements, mainly by Wilmer

The ancestry graph of my integration branch is getting more and more complex every day.

comments.

bzr foreign branches

meta = {'category': bazaar, 'date': Mon 21 November 2005}

Today I spent some time working again on foreign branch support for bzr. I got quite far, and can now run ‘bzr log’ and ‘bzr viz’ on remote Subversion branches.

The big hurdle to take were the Python bindings for Subversion, which are a pain to work with. Because these bindings were generated with SWIG (and haven’t had enough customization by humans), they very much look like C functions that can be called from python. The programmer has to worry about memory management, some functions with callback methods can not be used and passing an incorrect parameter usually results in a segmentation fault.

Most commands appear to run very slowly, but I found out this was caused, while I had initially blamed bzr, by ‘svn ls’ being extremely slow. It takens up to a few minutes to get a list of all files in a repository. This is of course a big problem if you’re trying to generate 2000 inventory objects, one for each revision….

bzrk screenshot

comments.

bzr hook for CIA

meta = {'category': bazaar, 'date': Sat 19 November 2005}

While trying to work on foreign branch support today, I got distracted and hacked up a small post-commit hook for bzr that submits commits to CIA. Doing stuff like this is trivial to do with bzr if you know some python.

comments.

trac hook for bzr

meta = {'category': bazaar, 'date': Wed 09 November 2005}

Since we’ll be using trac as the bug tracking system for BitlBee and bzr for source control, we won’t be able to use the default post-commit-message-hook, which comes with trac. This script usually makes sure that whenever a commit is done that references a bug, this gets mentioned on the page of that particular bug in trac.

I’ve hacked up a quick plugin for bzr which implements the same thing for the combination of bzr and trac. This isn’t the ideal solution since it requires that the script is running on the same host as the trac server, which is sometimes not the case as people push changes to their server rather then log in to their server and merge and commit the changes from their workstation.

The proper fix is probably getting trac itself to get information like this from the commit messages. It already detects new commits (they are shown in Timeline) and knows how to parse them, so something like that shouldn’t be very hard to implement.

comments.

Bazaar-ng

meta = {'category': bazaar, 'date': Wed 19 October 2005}

Over the past few days I’ve been working on random bits of Bazaar-ng. Lots of interesting things are happening in the bzr world.

I’m now working on a plugin that adds support for Subversion branches.

comments.

Bazaar-ng and tailor

meta = {'category': bazaar, 'date': Sun 25 September 2005}

Over the last few days, I’ve done another attempt to generate a Bazaar-NG version of Samba4 using tailor. I had to fix a couple of small bugs but got it working eventually. It took me about 8 hours for 5924 revisions using the following tailor configuration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

#!/usr/bin/env tailor

"""
[DEFAULT]
verbose = Yes

[samba4]
source = svn:samba4
target = bzrng:samba4
refill-changelogs = Yes
state-file = samba4.state
root-directory = ~/bzr/bzr.samba4
before-commit = samba_remap_authors

[svn:samba4]
repository = svn://svnanon.samba.org/samba
module = /branches/SAMBA_4_0
use-propset = Yes

[bzrng:samba4]
repository = ~/bzr/samba4
"""


def samba_remap_authors(context, changeset):
    authors_map = {
       u'metze': u'Stefan Metzmacher',
       u'tridge': u'Andrew Tridgell',
       u'abartlet': u'Andrew Bartlett',
       u'tpot': u'Tim Potter',
       u'jerry': u'Gerald (Jerry) Carter',
       u'vlendec': u'Volker Lendecke',
       u'crh': u'Chris Hertel',
       u'jra': u'Jeremy Allison',
       u'jelmer': u'Jelmer Vernooij',
       u'vance': u'Vance Lankhaar',
       u'derell': u'Derell Lipman',
       u'gd': u'Guenther Deschner',
       u'lmuelle': u'Lars Mueller',
       u'herb': u'Herb Lewis',
       u'jht': u'John Terpstra',
       u'jmcd': u'Jim McDonough',
       u'stevef': u'Steve French',
       u'jpeach': u'James Peach',
       u'mimir': u'Rafal Szczesniak',
       u'ab': u'Alexander Bokovoy',
       u'deryck': u'Deryck Hodge',
       u'lha': u'Love H\uffffrnquist \uffffstrand',
       u'idra': u'Simo Sorce',
       u'rsharpe': u'Richard Sharpe'
    }
    author = changeset.author
    if authors_map.has_key(author):
        changeset.author = "%s <%s@samba.org>" % (authors_map[author],author)
    return True

This branch is now up on samba.org. You’ll need the bzr “newformat” branch in order to check it out.

I’m a bit disappointed by the speed of “bzr branch” (takes around 3 hours when run locally, pulling in those ~6000 revisions).

Branching from a remote branch still gives me an error (this branch is up at http://samba.org/~jelmer/bzr.samba4/ and is the same I pull from locally):

1
2
3

bzr: ERROR: 'RemoteBranch' object has no attribute 'weave_store'
  at /usr/lib/python2.4/site-packages/bzrlib/fetch.py line 92, in __init__()
  see ~/.bzr.log for debug information

comments.

Version Control Systems

meta = {'category': bazaar, 'date': Tue 06 September 2005}

It’s been a while since I’ve written about version control and the landscape has changed quite a bit since then. Writing your own SCM seems to be the latest hype…

I’m currently using Subversion for most of the projects I work on (including those on Windows). Several other systems look interesting. I especially like darcs, as it is written in Haskell and has an elegant UI, though it is horribly slow. Bzr looks very promising, though its doesn’t really store data efficiently at the moment.

Another very interesting project, and a very useful one now with all the various SCM’s around, is tailor - a tool that can do conversions between the various projects.

comments.

Partially working upgrade paths

meta = {'category': bazaar, 'date': Mon 29 August 2005}

The one-way upgrade from Samba3 to Samba4 is now partially working! There are both a web-frontend and a console utility that can do an upgrade, given a libdir (usually /var/lib/samba) and a configuration file (usually in /etc/samba/smb.conf).

Last night, I rewrote most of the conversion code to be in EJS rather then in C. One of the positive things about this is that I can use embedded LDIF inside of the JavaScript code and that I can build on the existing Samba4 provisioning code (which is in EJS as well). Writing EJS wrappers for my existing C code was easier then I had thought.

One of the other things I did today is add a fallback mechanism for ldb_map where it can store the data that could not be mapped. There are now two types of records in ldb_map: those that are partially mapped (mapped, but might have one or two attributes stored in the fallback database) and those that are completely stored in the fallback database.

Below are some screenshots of the upgrade procedure in SWAT: /blog/uploads/screenshots/upgr1.png /blog/uploads/screenshots/upgr2.png /blog/uploads/screenshots/upgr3.png

comments.

Version Control Systems

meta = {'category': bazaar, 'date': Tue 30 March 2004}

I have been using CVS to store my source code and documents for the past couple of years. CVS works quite well, because it makes synching data between various computers easier, doesn’t require you to make a backup of your files every time they change and makes it easier to work on a project together with others.

However, CVS has its glitches. Renaming/moving files isn’t really handled - there is no notion that a file once had a different name or that its reincarnation is a different file. Secure access to a repository is a pain, especially if you’re using windows. Commits are per-file instead of per-changeset. It is a pretty poor tool for code management, but it’s well known, and it works.

Now that Subversion and GNU arch are becoming more and more widely used, I’ve been checking out some of the newly available VCSes.

After reading a couple of webpages, I have decided to go with Subversion. The two important reasons for this are the fact that Subversion runs much better on Microsoft Windows (a couple of my projects are in MSVC), and that migration from CVS to Subversion is quite easy.

Other than that, arch is a nice project and I’d really like to switch to using arch once it is stabler and has improved win32 support (if it ever will..).

comments.