Exchanging changes without a server

[John Arbash Meinel]

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

Dmitri Pissarenko wrote:
> Hello!
> 
> Thanks for your answers!
> 
>> Is this during the initial setup phase? After having exchanged a
>> few patches?
> 
> It happens after a few patches have been exchanged.
> 
> * * *
> 
> I think it would be much simpler, if it were possible NOT to keep
> track of changes of all the external developers.
> 
> I. e. at the beginning of each iteration I send to the external
> developers the ENTIRE history patch of my code base.
> 
> See activity diagram in file at
> 
> http://sw-dev.at/resources/2010_05_12_bazaar.pdf

I'm pretty sure step 3 is:

 bzr send ../user1 -o ...

The reason is that you are sending the content of "." relative to the
supplied URL. since they are working in "work" they want to send the
history relative to the gatekeeper.

> 
> My questions are:
> 
> If I want
> 
> a) the gatekeeper send the external developers the entire history and

I don't think you always want to send the entire history. You probably
want to have a fairly static "checkpoint" of history, and then send all
the changes relative to that. Because that initial checkpoint is static,
you can keep that patch file around in case someone needs to bootstrap,
but then all the 'new changes' patches don't have to include the
complete history yet-again.

> b) exchange code changes via e-mail attachments,
> 
> are then the commands given for each step in the diagram correct?
> 
> Thanks in advance
> 
> Dmitri
> 
> 

As such I would probably do:

bzr init-repo --no-trees repo
cd repo
bzr init baseline
cd baseline
bzr pull -r ??? ../trunk
cd ..
bzr init empty
cd baseline
bzr send ../empty -o baseline.patch

After that point, I would have:

bzr branch baseline gatekeeper
bzr co --lightweight gatekeeper work
cd work
bzr send ../baseline -o YYYY-MM-DD-gatekeeper.patch

All integration, etc done by the gatekeeper goes into this branch. And
the gatekeeper continues to generate patches relative to the current
baseline. For example:

gk> cd work
gk> bzr merge $OTHER.patch
gk> bzr commit -m "Landing the changes from OTHER"
gk> bzr send ../baseline -o ../project-gk-2010-05-18-`bzr revno`.patch

# Boostrapping user for the first time
user> bzr init-repo --no-trees repo
user> cd repo
user> bzr init baseline
user> cd baseline
user> bzr pull --overwrite baseline.patch
user> cd ..
user> bzr branch baseline gatekeeper
user> cd gatekeeper
# User only needs 'baseline.patch' and the most recent 'gk' patch.
user> bzr pull ../project-gk-2010-05-18-1234.patch
user> bzr branch gatekeeper myfeature
user> bzr co --lightweight myfeature work

== Integrating work from user ==

# User does work
user> cd work
# make changes
user> bzr commit -m "Initial work"
# submit to gatekeeper
user> bzr send ../gatekeeper -o ../myfeature-YYYY-MM-DD-1.patch
# user does more work, changes, etc
user> bzr commit -m "A few more touchups"
user> bzr send ../gatekeeper -o ../myfeature-YYYY-MM-DD-2.patch
# send it to gatekeeper


# Gatekeeper
gk> cd work
gk> bzr merge ../myfeature-YYYY-MM-DD-1.patch
gk> bzr st
gk> bzr diff
# run test suite, review, etc
# Not ready yet
gk> bzr revert

...
gk> bzr merge ../myfeature-YYYY-MM-DD-2.patch
# review, etc
gk> bzr commit -m "Merge myfeature"
gk> bzr send ../baseline -o ../project-gk-`date +%F`-`bzr revno`.patch
# publish to users


# User
user> cd ../gatekeeper
user> bzr pull ../project-gk-2010-05-19-1235.patch
user> cd ../work
user> bzr merge ../gatekeeper
user> bzr commit -m "Bring in the latest mainline tip."
# keep hacking



Note that the user can asynchronously decide when to pull updates from
gatekeeper. The patches user sends to gatekeeper will always apply, even
if they occasionally contain data that gatekeeper already has (as long
as user always only does 'bzr pull' in his gatekeeper branch.)


There are things that could be done if you really want 'minimal' patches
to be sent via email. But this is probably the workflow I would
recommend. As it means you shouldn't ever get a patch that needs more
context, even without people being very careful. (By creating deltas
against something that you know the other person has, because they
*sent* it to you. Rather than on something you assume they have, because
you sent it to them.)

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

iEYEARECAAYFAkvyyeAACgkQJdeBCYSNAAP4awCfZPt4ehIdTSsK4aRj8iFB0vos
EV8AoI/5WJ0orpOX8DTxk8Afl0N+SqQx
=psO3
-----END PGP SIGNATURE-----