my source code managment strategy for shindig

[David Primmer <da...@gmail.com>]

Hello all, If we had an active wiki, I might post something like this
there. It's my attempt to work on a very active (! yah) open source
project.

I've found that working with Shindig, because of the high churn rate
of the code requires some very deft SCM work. To make this easier, and
inspired by Santiago Gala's comments on his use of Git on this list, I
started using a DCVS called Mercurial (hg). I've had experience with
Bzr and Mercurial. I use a Unix and Windows so I needed something that
worked cross-platform. TortoiseHG is it. Git is similar and may work
for you. I don't know if it has the same tools to integrate with svn
though.

See this very detailed blog post about converting form SVN to
Mercurial. http://ww2.samhart.com/node/49 Essentially, you want a svn
working copy of the Shindig trunk that is also a Mercurial repo. Then
you can 'bridge' your changes in other cloned Mercurial repos and
eventually either submit them with your svn client or generate a
patch.

As others recommended, I tried hgsvn,
http://pypi.python.org/pypi/hgsvn and it worked like a charm. You can
follow the instructions to get what I got here:

In a dir that will host many trunks of Shindig...

$ mkdir svn-hg && cd svn-hg

$ hgimportsvn http://svn.apache.org/repos/asf/incubator/shindig/trunk/ .
your working copy has no source files in it at this point. Just the scm metadata

$ hgpullsvn
this will pull each revision starting from the first and hg commit
each one. This means that you will have the full svn history in your
hg repo. There may be a shortcut if you don't want all this history
but I haven't tried it. It took a good 10 mins and the hgpullsvn dies
3 or 4 times. However, I could restart it with no problem and it did
work.

Here's my layout

shindig\
    svn-hg\ < this has the combined hg and svn. It' is clean of builds
and only has the new files i'd like to create patches for
    trunk-build\ < this is a hg clone of svn-hg that is only building
with cmd line
    trunk-work\  < this is a hg clone of svn-hg  and contains a
working, building, eclipse env for doing a specific task
    trunk-morework\ < this is a hg clone of trunk-work and contains a
branch of the work in trunk-work
    ....etc... on and on.

One of the nice things about working with Mercurial clones instead of
svn is that they're not littered with .svn folders.

I globally .hgignore svn files and svn ignore hg files.

svn-hg is the most important folder and I'm very careful not to work
in it. It took the longest to create and has the most stuff going on.
I use it as a downstream copy of the Shindig repo and change revisions
all the time. It's mainly a place to merge Shindig SVN and what I have
going on in other Mercurial clones of it. When I get what I want
working in my HG clone, I "hg pull" from the clone into svn-hg and do
the svn-add's that are necessary to get the SVN working copy in a
state that it can produce a good diff for others on the project. I can
revert the SVN state back to whatever I need it to be once the patches
are created. I can update it if I think I need to move up what "my"
SVN head revision is. Cloning this dir with Mercurial is really easy
and this is the way you keep the churn at bay.

When I want to test a new thing that just came out from the project, I
usually just checkout a new pure SVN working copy and do mvn build
stuff in it.

Hope this helps.