best way to manage local code changes which shouldn't be propagated
Arne Babenhauserheide
arne_bab at web.de
Thu Jan 15 12:33:37 CST 2009
Am Donnerstag 15 Januar 2009 17:51:03 schrieb Georg:
> The use case here is for local shortcuts, maybe temporary bug
> fixes/workarounds until the owner of the respective code module comes up
> with the proper fix, maybe disabling certain features not useful in a
> development environment (license checks ... :-)). These I want to apply
> only in my local environment, they should never be propagated. Other code
> changes which I do (deliverable code) should be propagated.
How about having an outgoing and a work repository?
in the work repository you just use a private named branch into which you
regularly merge upstream changes. You do work you want to propagate in the
default branch and things you don't want propagated in the private branch.
I just tested the workflow and created a rather verbose script to show how to
use it. You can simply run it to test the workflow:
------ ------ ------ ------ ------ ------ ------ ------ ------
#!/bin/sh
# Track private changes and an upstream repo.
# The private changes should never be propagated.
### Setting the environment ###
# First create upstream (not part of teh main workflow)
hg init upstream
cd upstream
echo "upstream code" > code
hg commit -Am "upstream 1"
cd ..
### The workflow ###
# First create an outgoing clone
hg clone upstream outgoing
# Then create a working cloneclone
hg clone outgoing work
## Private changes
# Do private changes in work
cd work
hg branch private
echo "private changes" >> code
hg commit -m "private 1"
cd ..
## public changes
cd work
# First update to the default branch
hg update default
# Then do the changes
echo "public changes" >> code
hg commit -m "public 1"
# Finally merge the public changes into the private changes.
hg update private
hg merge default
# resolve any conflicts, then commit
hg resolve -m
hg ci -m "merge default into private."
cd ..
## Propagate public changes
# Pull the public changes into the outgoing repo
cd outgoing
# Pull only the default branch
hg pull -r default ../work
# Check the log
hg log
# Push the changes.
hg push
cd ..
# Check upstream
cd upstream
hg update
hg log
cd ..
## Integrate upstream changes
# First add some upstream changes
cd upstream
echo "upstream changes" >> code
hg commit -m "upstream 2"
cd ..
# Then pull these changes into work
cd work
hg pull ../upstream
# Merge the changes into the private branch
hg update private
hg merge default
# resolve any conflicts, then commit.
hg resolve -m
hg ci -m "merge default into private."
cd ..
### Notes
## Possible improvements
# This workflow can be made more efficient
# by setting the default repo of work to upstream,
# as well as setting the default of outgoing to work
# and the default push of outgoing to upstream.
# It can be made safer by setting default-push of work to outgoing,
# so even an accidental push inside work won't make your private changes
public.
# The workflow in four sentences:
# You pull changes into work but push them via outgoing.
# Your private changes live in a private branch in work.
# You only pull the public branches from your work repo into outgong.
# You never push from work.
## Alterations
# You can also push from work, but then you have to use the -r specifier
# in the same way as when you pull from outgoing:
# hg push -r default
------ ------ ------ ------ ------ ------ ------ ------ ------
Best wishes,
Arne
--
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://selenic.com/pipermail/mercurial/attachments/20090115/b517f935/attachment.pgp
More information about the Mercurial
mailing list