Commit hooks on smart server

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicholas Allen wrote:
> Hi,
> 
> I realize that this is not implemented yet but I was wondering how hard
> this would be to do? I think without this we can't consider bzr as we
> need to keep all our developers up to date with changes made in various
> branches as they happen. With svn we get an instant email detailing the
> changes a developer has made, even when it is to a private branch.
> 
> What is the expected timetable for implementing this or can someone
> point me in the right direction so I can perhaps take a look at it?
> 
> Thanks,
> 
> Nicholas Allen

At this point, there is only the basic amount of RPC protocol written
for the smart server. Which means ATM it only acts as a remote
filesystem. Over the next few releases, we plan on extending the
protocol, to allow much higher level semantic operations, rather than
file-level operations.

At that time, it should be pretty easy to add hooks, so that when a
high-level operation occurs you can do something specific.

For your specific needs, we have a few solutions:

1) Use a PQM to manage the central trunk, which will send an email about
any successful merges. But yes, this doesn't send emails for
user-specific branches.

2) Have users configure the 'bzr-email' plugin found here:

https://launchpad.net/products/bzr-email/

This can be configured to send an email after every commit. It has some
positives and negatives.
  a) It requires users to set up on their personal machine, rather than
     having it set up on the server side. So each person needs to
     configure it.
  b) However, because bzr lets you create local branches that never
     touch the server, it means that users can send out emails even when
     they don't push their changes (yet). Which means that you can have
     people updating each other even if they decide to work locally.

3) Use the bzr-svn plugin, but leave your backend as SVN. The bzr-svn
plugin is still approximately beta stage. In that it works, and your
data is safe, but some performance issues remain. Some comments:
  a) It can interoperate between an SVN repository and bzr branches. (As
     in you can branch from SVN to a bzr branch, and merge that back
     into SVN, and so forth)
  b) It uses similar tags as SVK, so that it actually does track
     merging, etc.
  c) You retain SVN as your upstream server, so any hooks that you have
     already written should continue to work. (Note that if users start
     using offline bzr branches, you obviously won't get email updates
     for things they don't push to SVN)
  d) I don't believe it allows you to commit an out-of-date tree. So you
     still have the 'must update before commit' issues. Though honestly
     you are cheating if you are relying on SVN to allow you to commit
     without updating, but still expect the source code to compile at
     any given version. (With SVN I can commit a revno 101, where most
     of my source is at version 99, but you did some big updates in 100
     that I never saw. And then when someone else does a checkout of 101
     ... *boom* everything is broken). So I understand why SVN seems
     nice when you have a high commit rate. Even better, though, is to
     have people working on feature branches that can operate without
     stepping on each other's toes until everything is ready to be
     merged.

4) Use the 'foreach' command from the ezbzr plugin:
   http://www.natemccallum.com/software/ezbzr/

   You can setup a cron job on the server which just polls all of the
   branches in a given repository and looks for updates. And then it can
   send out emails if it sees things change. While this doesn't happen
   at exactly the same time as commit, it actually has some advantages.
   In that if someone commits 4 times offline, and then does a push of
   all 4 to the shared location, you have the option of sending that out
   as 4 emails or 1 combined email.


There are probably other solutions. These are just the ones that I know
exist right now.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFP3JNJdeBCYSNAAMRAo9SAJ9r14J5DyZwjKiDERSOeVt7++BwcwCdHc0f
Eiy457q+UON2yDdwGsIJ62U=
=pzbn
-----END PGP SIGNATURE-----