[Unison-hackers] Unison on launchpad (was: [unison-users] Broken unicode handling in unison 2.27.57)

[Martin von Gagern]

Hi!

Benjamin Pierce wrote:
> I'm willing to help with repository issues, but I'd prefer to wait a
> little till it's clear that this project is making progress before
> sinking a lot of time into setting things up.  Would it make sense just
> to take a copy of the sources, put it somewhere convenient for
> collaboration among whoever is interested in this, let things run for a
> little while, and then synchronize the two replicas and set up a way of
> keeping them in sync?

Russel Winder was so kind to create the unison group and project on
launchpad.net, and I've uploaded a bzr-svn import of the repository. I
think I'll keep that in sync manually for now, and when this works out
ask you to automate the synchronization.

The project page:       https://launchpad.net/unison
The developer team:     https://launchpad.net/~unison
Available bzr branches: https://code.launchpad.net/unison

The build relies on svn keyword substitution to keep track of the
current version number. bzr doesn't replace keywords by default, and has
a different idea of revision numbers as well, as they are per branch,
not per repository. I've attached a patch that deals with the situation
by finding the bzr revision number corresponding to the origin svn
revision, and starts counting from there. Should not cause trouble for
developers using svn, as it only gets called when the keyword isn't
expanded.

I've also improved behaviour of the build in case the mkProjectInfo
build fails. Without modification, this can lead to an empty
Makefile.ProjectInfo causing an empty $(NAME) and thus an empty
dependency in "buildexecutable:: $(NAME)$(EXEC_EXT)", so nothing was
build, and no error was signaled. Now I'm deleting files on error, and
depending on Makefile.ProjectInfo, so the build will fail.

Are you willing to merge this patch into the main unison trunk, or
should it exist as a separate branch on launchpad? I'd prefer a merge.

> P.S.  Since the discussion is getting pretty technical, I suggest we
> move it to the unison-hackers list.  I'll cross-post this there so you
> can just "reply all" and then edit headers.  (You'll need to sign up for
> that list, but you should do that anyway, since it's where commit logs
> get sent.)

Fine with me. And those commit messages will help me keep stuff in sync,
I believe.

I guess I'll soon get back to you with a wishlist of stuff I want
explained. Just a note for now: I found out Glib.Utf8 provides a
normalize function, so I might end up using that instead of camomile.

Greetings,
 Martin
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bzrbuild-260.patch
Url: http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20090504/dc5cb84c/bzrbuild-260-0001.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20090504/dc5cb84c/signature-0001.sig