[CODE4LIB] Version control and local changes

2011-05-09 Thread Yitzchak Schaffer

Hello all,

We primarily use Mercurial for version control, having migrated from SVN 
over the past year or so. I am currently trying to figure out the best 
way to version local (production) changes to controlled libraries. I'm 
still trying to understand the different branching possibilities of hg 
and git; this helped:


http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Seems to me like the best thing would be to maintain a production clone 
of the main, public repo, separate from the actual production code, and 
push/pull to and from this clone. This way it would be possible to test 
without polluting the production code and creating the mess of tweaks we 
have on our server now.


Does anyone have any success stories with this or another method?

Thx,

--
Yitzchak Schaffer
Systems Manager
Touro College Libraries
212.742.8770 ext. 2432
http://www.tourolib.org/


Re: [CODE4LIB] Version control and local changes

2011-05-09 Thread Gabriel Farrell
The great thing about any DVCS is how easy it is to clone repos, then
push and pull between any two clones.

Most of the projects I work on are on github (a couple still in hg on
googlecode), so that's the public repo. I have a live clone of the
public repo, but between the two I have staging (same machine and data
if possible) or dev (similar environment and a copy of the data)
clones. Sometimes both. Each clone pushes and pulls from the next one
up:

live - staging - dev - public

All public/upstream changes must pass through dev and/or staging
before they go live. At each step along the way, you can decide which
code is local and which needs to bubble back up to public. You may
find branches within your dev clone useful for merging upstream
commits in with local changes before passing them down the chain.
You're also free to make other clones anywhere along the chain for
experimental development and testing of new environments.

One thing I've learned in all of this, though, is no matter how
fantastic your VCS, the more the project allows you to put local code
in files you can stick in your .(git|hg)ignore, the less you'll have
to keep track of on each commit.


On Mon, May 9, 2011 at 12:55 PM, Yitzchak Schaffer
yitzchak.schaf...@gmx.com wrote:
 Hello all,

 We primarily use Mercurial for version control, having migrated from SVN
 over the past year or so. I am currently trying to figure out the best way
 to version local (production) changes to controlled libraries. I'm still
 trying to understand the different branching possibilities of hg and git;
 this helped:

 http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

 Seems to me like the best thing would be to maintain a production clone of
 the main, public repo, separate from the actual production code, and
 push/pull to and from this clone. This way it would be possible to test
 without polluting the production code and creating the mess of tweaks we
 have on our server now.

 Does anyone have any success stories with this or another method?

 Thx,

 --
 Yitzchak Schaffer
 Systems Manager
 Touro College Libraries
 212.742.8770 ext. 2432
 http://www.tourolib.org/