[wp-hackers] Switching from SVN

Fri Dec 10 15:21:28 UTC 2010

At this point, I think this conversation isn't going to go anywhere, but I
want to make one last comment before dropping off the thread.

When I first started working with WordPress, I had no idea what version
control was.  I wrote a plug-in and sat on it for weeks because I couldn't
figure out how to get it into the repository.  For someone new to version
control, saying "use Subversion" doesn't really describe the process ...
particularly when you have no idea what Subversion is.  All I wanted to do
was email or FTP my plug-in to the server.  That would have been easy, and
once I figured out what Subversion was I was furious.  Why use a command
line tool when I could more easily drop a ZIP file in a folder through
FileZilla?  But I slowly worked my way through it, typing in command line
statements that I didn't understand but which were laid out in the tutorial.
 Most of the time it worked ... sometimes, though, tagging a new version
broke (with a cryptic "file already exists" error) and I'd have to force a
reversion and try to commit again.  Don't believe me?  Look at the
Subversion logs for any of my plug-ins ... sometimes following the tutorial
didn't work and I was left very confused, upset, and frustrated at the
entire WordPress project.

I finally embraced Subversion during a client project.  Before then, I'd
only seen it as a distribution tool, *not* as a version control system (I
didn't understand version control beyond the concept of point releases and
named versions).  I was working on a project for a client - a custom
.NET-based CMS.  Things were going well, I was cranking out code and
everyone was happy.  One day, I was overhauling the data access layer
(sanitizing queries I'd forgotten to protect from SQL injection) and got a
phone call in the middle of the day.  It distracted me, and over the
30-minute call I forgot what I'd worked on.  I came back, looked at a
half-written line of code (literally), shrugged, and finished what I thought
I needed to finish to complete the project ...

... and I broke everything.  Somewhere I had forgotten to set a variable,
assign a type, or put a semi-colon in a query.  I looked for about 2 hours
through my 30k lines of code and couldn't find the problem ... so I just
started hitting ctrl+z in Visual Studio until I finally got back to a
version of the codebase that would build.  I had to re-produce a lot of my
work after that, and I was very burned out by the whole process.

Ever since then, I commit *everything* when I get to a logical stopping
point and can test, whether I'm done with the project or not.  When I'm on
my own repo, no one cares how many commits I have.  So for my WordPress
plug-ins, I actually have a separate repository on my local network that I
commit to.  When I get to a point where I want to package a new release, I
export the plug-in from my repository and copy the files into a folder
synced with the WordPress repo.  Then I commit and release my plug-in.

When I'm working entirely on my own, it's a good system.  But, I joined a
company about a year ago where multiple developers were working on the same
codebases at the same time ... and all hell broke loose.

I'd update my working copy, code on a project for a few hours, then try to
commit ... only to find out that a colleague had been working on the same
files that day.  I'd spend an hour or two reconciling conflicts while
merging my changes in to his.  It was a major PITA with just two of us, so
when we expanded the team to 4 people we decided to investigate other tools.

First we looked at Git because it seemed so powerful.  It was, and I loved
it.  Every project we started (each of our projects has a separate issue ID,
similar to Trac) was a different branch.  So I'd work on my ticket for a day
or so, write lots of code, and get it to work.  I'd commit whenever I
reached a logical pause point (whenever I'd finished enough code to test it)
and finally merge it back into trunk when it was ready to go.  Trunk only
ever showed merges from completed projects, so it stayed very clean ... but
if you found a problem in the code downstream, you could always track it
back to the actual developer and changeset.

In the end, though, we went with Mercurial.  It's very similar to Git, but
with slightly less command line power.  We went that direction, though,
because the SVN-to-Hg repository conversion tools were better and because
TortoiseHg was more stable than TortoiseGit at the time.  We still follow
the same workflow - each project is a separate branch - and it's working
wonders.

The biggest complaints I have about SVN: branching/merging is a hassle and I
can't commit as I work on projects.  As I said before, I like to work in
stages when I'm working on a larger project and being able to commit to
something to track my changes is really what I want to accomplish.  I
commit *everything* when I get to a logical stopping point and can test,
whether I'm done with the project or not.  When I'm on my own repo, no one
cares how many commits I have.  When I'm on a shared repo, I work in a
branch so no one cares until I merge but they can still see my changes,
create diffs based on my branch, and test/critique/contribute to my branch
as I work on it.

So in the end, Git and Mercurial work for me.  So does Subversion.  And yes,
switching from any one tool to any other *will* be difficult.  You'll have
to re-learn old behaviors and come up-to-speed with a new platform.  But it
can be done, and you have to consider more than your own workflow when
making a decision.  When I first learned the local versus hub repository
system of Git I hated it with a passion.  I was used to Subversion and I
didn't see the value in having my own local repository.  But I gave it a
try.

On Fri, Dec 10, 2010 at 5:16 AM, scribu <mail at scribu.net> wrote:

> On Fri, Dec 10, 2010 at 3:01 PM, Mike Schinkel
> <mikeschinkel at newclarity.net>wrote:
>
> > On Dec 10, 2010, at 7:44 AM, Mike Little wrote:
> > > If you are working on a fix for the current release, then you need to
> > work
> > > against the current stable *branch*.
> >
> > So does a *branch* different from the current release?  I'm as confused
> by
> > all this as Otto is confused by Git.
> >
>
> Yes, it does.
>
> The current release is under tags/3.0.3.
>
> The stable branch is in branches/3.0.
>
> At the moment, the 3.0 branch is identical to the 3.0.3 tag, because there
> haven't been any commits made yet, but that's not always the case.
>
> > I'm not sure what could be any simpler than the instructions here
> > > http://wordpress.org/download/svn/
> > >
> > > There are  only 4 (svn) steps.
> >
> > It's not running SVN that is complex, it's getting the right code to run
> > SVN against that can be complex.
> >
>
> A possible git workflow:
>
> 0. Clone the WP repo: git clone git://some-mirror-url.com/wordpress.git
>
> 1. Make some changes on the stable branch
>
> 2. Switch to dev branch (without loosing changes): git checkout development
>
> 3. Test changes and make patch: git format-patch > patch.diff
>
> 4. Switch back to stable branch: git checkout stable
>
> Because you have the entire repo stored locally, switching branches is a
> snap.
>
> Of course, there are some catches, like a possible db-upgrade, which might
> be harder to change back from.
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>