cfwheels and git?

[Mike Henke]

I am big into advocating CFWheels and git. I wonder if CFWheels
should start using git so CFWheels could promote social code and the
CFWheels community. CFWheels code could be hosted on GitHub.

[Chris Peters]

I can only offer a few thoughts to this because it seems like we have a system that works pretty well with the SVN repository.

I do know that there are some great integration points between the Issues and Source sections of Google Code, though I figure that GitHub may very well have a similar system. (I'm not too familiar.)

Is there a SVN-to-git migration tool? We have a lot of history stored in our SVN repository.

Usage of GitHub would definitely make us appear more hip and snobbish (which we should borrow some of the enthusiasm/snobbery from the Rails community, IMO... it's the best way to make friends ;)). I'm not sure that that's a great reason to switch, but I thought I would throw that out there.

[Mike Henke]

> I do know that there are some great integration points between the Issues
> and Source sections of Google Code, though I figure that GitHub may very
> well have a similar system. (I'm not too familiar.)

GitHub Issue Tracker
http://github.com/blog/411-github-issue-tracker

> Is there a SVN-to-git migration tool? We have a lot of history stored in our
> SVN repository.

Guides: Import from Subversion
http://github.com/guides/import-from-subversion

[Mike Henke]

Moving tickets over from Google Code maybe an issue though.

On Sep 25, 11:24 am, Mike Henke <henkem...@gmail.com> wrote:
> > I do know that there are some great integration points between the Issues
> > and Source sections of Google Code, though I figure that GitHub may very
> > well have a similar system. (I'm not too familiar.)
>

> GitHub Issue Trackerhttp://github.com/blog/411-github-issue-tracker

[tpet...@gmail.com]

mike,

if you would like to contribute to wheels using git, you can do so by
forking the github repo:

http://github.com/rip747/cfwheels

chris,

github makes it painless to migrate over an svn repo. literally you
just create a repo on github and during the process you give it the
url to your svn repo and it does all the work for you.

however if you want, i've done it manually before and i could do it
again.

github also has issues and wikis and such, however their issue
tracking isn't nearly as feature rich as google code's which is why i
think everyone uses lighthouse as the ticket tracker.

http://lighthouseapp.com/

all that all being said.

as much as I LOOOOOOOOVE git and maintain the git repo, i think we
should stay on google code for the time being. my reason for this is
quite simple, there isn't a comparable git gui on par with tortoisesvn
yet. yes tortoisegit is getting there, but it does have some MAJOR
issues at the moment and until those issues are worked out I don't
feel comfortable migrating. most people are only familiar with using
svn through tortoisesvn and making the leap to using a command line
for all their operations would be a big learning curve.

however if everyone tells me to shut my mouth and wants to advocate we
move to git, i'm all for it.

On Sep 25, 10:38 am, Chris Peters <ch...@clearcrystalmedia.com> wrote:
> I can only offer a few thoughts to this because it seems like we have a
> system that works pretty well with the SVN repository.
>
> I do know that there are some great integration points between the Issues
> and Source sections of Google Code, though I figure that GitHub may very
> well have a similar system. (I'm not too familiar.)
>
> Is there a SVN-to-git migration tool? We have a lot of history stored in our
> SVN repository.
>
> Usage of GitHub would definitely make us appear more hip and snobbish (which
> we should borrow some of the enthusiasm/snobbery from the Rails community,
> IMO... it's the best way to make friends ;)). I'm not sure that that's a
> great reason to switch, but I thought I would throw that out there.
>

[Mike Henke]

tpetruzzi pretty much nailed the cons from what I hear.

> quite simple, there isn't a comparable git gui on par with tortoisesvn
> yet. yes tortoisegit is getting there, but it does have some MAJOR
> issues at the moment and until those issues are worked out I don't
> feel comfortable migrating. most people are only familiar with using
> svn through tortoisesvn and making the leap to using a command line
> for all their operations would be a big learning curve

[Mike Henke]

Maybe CFWheels could promote their GitHub site even if it isn't the
primary code repos.

How do you keep the two repos (SVN and GitHub) in sync?

[tpet...@gmail.com]

i'm STILL trying to cron working on my machine at home under cygwin so
that i can sync the repos automatically every 15 minutes or so. right
now, it's just a manual thing. when i get, i sync, when i go home, i
sync, then i take shower because, you know, i sync :)

[tpet...@gmail.com]

the more i think about my previous answer the more i'm thinking that
it might have been just a cop-out and not true to heart.

if there's one thing that i don't like about svn it's the branching
and i think this is where git could help us. now i don't know how the
rest of the world programs, but even when i used svn, i use branches a
lot. to me, unless you're fixing a quick and down and dirty bug, you
should be working on a branch and not off trunk (master in git). my
whole reason for it is because trunk should always be in a working
state and if you're working on a feature of fixing a mess loads of
bugs, it could leave trunk in an unstable state. also because, when i
program websites, trunk matches what has been pushed to or going to be
pushed to production.

after working on my feature in a different branch, i merge it back
onto trunk and push it live. that all happens in theory with svn. in
reality i'm sitting at my desk for around 2 hours kicking, screaming,
crying and feverishly trying to get the branch that i've been working
on for the last week and a half merged back onto trunk. most merge
sessions with svn ended with me opening a bottle of patron silver and
pack of parliaments and punishing my liver and lungs. it was never
pretty and never easy. this was probably the reason why i only ever
worked on about 2 branches max. i just couldn't keep going through the
stress of merging svn branches, i just couldn't.

let's hop over to git now and see why this hot, spicy, sexy goddess of
the scm world has become my new arm candy. now i said above i only
worked with at most 2 svn branches at a time because of the problem
with merging. i don't have this issue with git. in fact i don't think
i've worked with only 2 branches since using git, i'm usually using
around 8 or 9 most of the time. in fact, i pretty much create a branch
of just about everything i do with git. need to fix a bug, branch,
need to add a feature, branch, add a comment, branch. i branch more
then i breathe now because git make merging these branches painlessly
easy. If something goes wrong I just "git reset --hard HEAD@{1}" and
try the merge again. i'm not afraid of messing anything up.

also did i mention that creating a branch with git is almost instant
as opposed to dismal with svn.

the other thing i can stand about svn is the total restrictions on how
you commit your changes. for instance, take a moment and look one of
the recent commits:

http://code.google.com/p/cfwheels/source/detail?r=3106

notice what the commit message saids "fixed issue 271 and refactored
code". so you're all looking at this right now and saying, "so what's
the big deal". well i'll tell you what the big deal is, that one
commit should be two commits. one for the fix and one for the
refactor. now i bet the reason why it's in one commit was because the
refactor was worked on while the bug was being fixed. there's no
problem with that, we've all done it. the problem comes when it's time
to commit the changes. if you use svn, you're screwed. svn only allows
you to commit files and not "hunks" of the file. in other words you
can commit myfile.cfm as a commit, but not lines 1-10 as one commit
and then lines 30-40 and 45-50 as another commit.

now with git i have total control over how i commit my code. if i want
to i can just do a "git add -i" and pick and pack away the commits how
ever i want. I don't like something i did, "git reset --soft HEAD~1"
and the recent commit is removed and the changes back to the staging
area. seriously, i'm not giving git enough credit in this feature
because it's really hard to explain the power behind this and you just
have to use it once to realize it. i would STRONGLY suggest you take 5
minutes and read the two posts on gitready.com that cover this:

http://www.gitready.com/intermediate/2009/01/14/interactive-adding.html
http://gitready.com/advanced/2009/01/15/piecemeal-staging.html

the final reason and main reason why i made the switch to git, it's
decentralized, end of story. think of this for minute.... lay back and
close your eyes.... they're closed right? google code dies a horrible
death, the wheels repo is GONE. anyone have a backup of the entire
repo right now, anyone? of course you don't, because you've all
checked out trunk to your working copies. now it's not the biggest
deal because there really aren't a lot of branches in the repo and the
tags can get recreated. about the biggest loses would be the wiki and
the issues. but say we had 25 branches up there at various stages,
what would we do then? Even bigger problem, with the repo being gone,
how are you going to submit those changes that you've been working on
for the last 5 hours? You're not.

if github went into the toilet right now and was unavailable (which it
will be this Sunday when they move hosts), i could care less. since
every "git clone" basically pulls down the ENTIRE repo, i have all my
branches, tags right on my local machine. being that git is
decentralized, i can commit, branch, tag, rebase, merge all day. only
when i'm done doing what i want and want the rest of the world to see
my work do i "git push origin" and all of the work i've done gets
published. yes you read that right ONE COMMAND and all of the
branches, tags and changes i've done locally can get pushed to github,
ONE COMMAND. if i just want to push my master branch, i just do "git
push origin master".

so yeah this post was LOOOOONG winded, but like i said, i wanted to
post from the heart as to why even though i know right now there isn't
a comparable gui for git like there is for svn, it shouldn't stop us
from moving over to it if we want to. the benefits of using git FAR
out weigh the time it will take to learn the commands. it's going to
be painful, it was for me, but after using it for the past year i
can't and won't go back to using svn, cvs, vss or any other
centralized scm.

the only final reason i'll give to moving to git is because that's
what everyone is moving to! we all work on wheels because we love it
and want to build something fantastic, but let's face facts, we also
do it to prove, sharpen and learn new skills to become more marketable
when we need to look for a job. it's easier to show a client or a
potential employer open source code then closed source. so, imagine
losing a job or a contract to someone who had that one more skill that
you needed and that skill needed today is working with scms.

[tpet...@gmail.com]

[Mike Henke]

I was thinking over the user interface question also. The CFWheels
team currently using SVN so only they are committing. Other potential
community changes have to send patches. ( I use patch loosely since
SVN has some patch cabalities I think.)

Does it really matter for the potential community changes if the
CFWheels team uses git since if the community change doesn't use git,
the change will still have to be sent as patch to the CFWheels team.

On the other hand, github gives community members the option of using
git and contributing seamlessly.

also every "git clone" basically pulls down the ENTIRE repo, is kinda
wrong. it actually pulls down the entire repo :-)

> as much as I LOOOOOOOOVE git and maintain the git repo, i think we
> should stay on google code for the time being. my reason for this is

> quite simple, there isn't a comparable git gui on par with tortoisesvn
> yet. yes tortoisegit is getting there, but it does have some MAJOR
> issues at the moment and until those issues are worked out I don't
> feel comfortable migrating. most people are only familiar with using
> svn through tortoisesvn and making the leap to using a command line

> for all their operations would be a big learning curve.

[Mike Henke]

The major hurdle is the current core committing team needs to agree to
switch and learn git. The community changes will come either way.

[tpet...@gmail.com]

well, i think i'm the only core member using git at this point :)

[s. isaac dealey]

> if there's one thing that i don't like about svn it's the branching
> and i think this is where git could help us. now i don't know how the
> rest of the world programs, but even when i used svn, i use branches a
> lot. to me, unless you're fixing a quick and down and dirty bug, you
> should be working on a branch and not off trunk (master in git). my
> whole reason for it is because trunk should always be in a working
> state and if you're working on a feature of fixing a mess loads of
> bugs, it could leave trunk in an unstable state. also because, when i
> program websites, trunk matches what has been pushed to or going to be
> pushed to production.

I must be really out of touch with the programming community... this
idea of trunk always being in a working state sounds to me like nonsense...
To me, if you want something that's in a working state, you get the
stable release (zip archive or in some cases an MSI installer). If
you're getting trunk from a source-control repo, that's a bleading-edge
release, and you should expect it to be in any given arbitrary state of
change either for bug fixes or new versions. If it's not working in some
way that's significant for something that you personally happen to be
working on, then you either need to coordinate with the other people who
are working on it, or you need to simply go back in the repo history to
the last tagged version (which should be a stable release version),
branch from there and work off of that branch until the trunk is in a
working state again. In other words, a large part of the whole point of
source-control is so that it doesn't have to always be in a working
state in the first place. But maybe that's just because I haven't worked
on any projects where the ratio of programmers to size of code made
managing the repo that way a hassle.

--
s. isaac dealey ^ new epoch
isn't it time for a change?
ph: 817.385.0301

http://onTap.riaforge.org/blog

[s. isaac dealey]

After reading through the rest of tony's message about the benefits of
GIT, my primary reasponse to... well just about all the things Tony
described as advantages is "ewwwww, gross!!!" But different strokes I
guess. Decentralization would be cool -- someone should strongly suggest
to the folks who maintain the SVN project that they provide
decentralized maintenance as an optional way of configuring a repo.

[Mike Henke]

Also SVN is linear in the history. git provides non-linear history,
so you could even cherry pick some code from a file and not the whole
file to commit. Example would be a quick critical bug fix while
working on a different more long term release. Try that in SVN :-)

[Mike Henke]

Everything is basically a branch in git. Also git doesn't track
files, it tracks content. Most SVN workflows, I have seen using SVN
have the working copy/trunk as development (unstable), might do some
branching off that, have a folder for each server stage like prod,
staging, and dev. Then from trunk, changes are merged to dev, tested,
then merged/moved to staging, and finally prod folder (stable).

[s. isaac dealey]

> Also SVN is linear in the history. git provides non-linear history,
> so you could even cherry pick some code from a file and not the whole
> file to commit. Example would be a quick critical bug fix while
> working on a different more long term release. Try that in SVN :-)

I think I might have to have the experience to really appreciate these
last couple of comments you made. (Like how some folks just don't get
dependency injection until they've worked on a really big / really
complex project.) But thanks for the attempt at clarifying, it is
appreciated. :)

[Russ Johnson]

In every company I have ever worked for while using SCM. The golden
rule is NEVER commit broken code to the trunk. Its just bad practice.

Your trunk should always build, no matter what. I know this concept is
foreign to alot of SVN users because of how difficult branching is
with SVN. And yes we suffered through it as well but maintained the
trunk as a working release.

With Git, this becomes much, much simpler. Especially with a tool that
I dont think anyone in this thread has mentioned, and thats rebase.

Once you start using git and experience how easy and powerful
branching in SCM truly is, you will never develop the old way again, I
promise you that.

[s. isaac dealey]

> In every company I have ever worked for while using SCM. The golden
> rule is NEVER commit broken code to the trunk. Its just bad practice.

I still don't understand the logic behind this idea. What was the
problem everyone was trying to overcome this way?

[Russ Johnson]

Think of it this context. If you were using continuous integration and
committed broken code to the repo, your builds would be broken...

Alot of projects support nightly builds, if you commit broken code to
the trunk or master branch, your nightlies are no good.

It seems that Im looking at this from the wrong standpoint though, it
seems that you should be trying to convince us that there is a logical
reason FOR committing broken or incomplete code to the repo. Your
trunk should aways build. Let me give you another scenario.

You have your repo and last week you tagged and released a new
version. Since that release you have been working on a new feature and
have been committing your broken/incomplete code to the trunk/master.
Now a serious security bug pops up in your latest release. Uh oh. You
cant just fix the bug from the trunk and push a new version, you have
all of your broken/incomplete code committed there with this new
feature. Now this might be extreme but this is an exact scenario that
happened to use once, it was not fun to deal with in SVN at all. Nor
would it have been proper with ANY scm tool.

Had we been building that feature in a branch, we could have easily
fixed the bug in a new branch, merged that into the trunk and pushed a
new release. Then once our feature is done, we rebase the branch so it
picks up our bug fix then merge with the trunk and we're done.

Does that help to shed some light on why your trunk/master should
always build?

- Russ

[Chris Peters]

I'd like to see Per, James, and Raul weigh in on this discussion.

Part of me says that we shouldn't mess with the process until after we release 1.0. Another part of me says that perhaps adopting Git would allow others to help out more easily, thus making 1.0 easier.

While I see the benefits of Git, I do see it as potentially slowing down our momentum (which has been going strong!) over learning a new tool mid-project.

For those of us on Mac, are there any good Eclipse plugins for Git? I use Eclipse/CF Builder personally.

Thanks for bringing up this issue and debating it passionately. I love to see shit like this. :)

[Russ Johnson]

There is an eclipse plugin, I think its called EGit... I havent used it since I use Texmate exclusively and I just find the commandline git process much faster and cleaner, especially once you setup some aliases for the commands in your bash_profile...

You can also checkout GitX if you are on mac. Its a good tool for visualizing your repo. You can view the branch structure, individual commits, diffs, etc... really handy for when you just need to "see" it.

[s. isaac dealey]

> Does that help to shed some light on why your trunk/master should
> always build?

Yes it does, thanks Russ. I'm still not entirely sold on the idea, but
that may be because I've not experienced the pain that others describe
with regard to merging branches in SVN either, so...

[tpet...@gmail.com]

> Yes it does, thanks Russ. I'm still not entirely sold on the idea, but
> that may be because I've not experienced the pain that others describe
> with regard to merging branches in SVN either, so...

i envy you. i've always had nothing but problems when it came to svn
merges, especially when they introduced the great concept of tree
conflicts in 1.6. :P

who ever came up with that idea should be falcon punched in the loins.

[s. isaac dealey]

Heh... granted, not that I haven't had my fair share of problems with
tortoiseSVN in general... go to commit something and get "you're not up
to date!" ... well gee, let's see, I'm the only one committing to this
particular repository, so that would be impossible... do the update, do
the cleanup, ARGH!

Though at least for me that has gotten better with time rather than
worse. But I don't branch much on my own projects and the companies I
worked for where they were using an SCM, they were always using
something way way worse than SVN like Surround or Perforce or in one
case MS SourceSafe (which was based originally on an old Perforce
version).

Surround was great, it would punish you for making the mistake of
deleting the wrong file from the repo by never, ever, under any
circumstances allowing you to undo the delete -- or create a new file
with the same name in the repo. So in essence, it's an SCM that demands
that you not ever make mistakes -- which I thought was the reason we had
SCM to begin with, because people make mistakes. ;)

[Jeff S.]

If you guys are seriously considering moving away from SVN, you may
want to look into Mercurial rather than Git. It's the DVCS supported
by Google Code, and there are instructions for converting a project
here:

http://code.google.com/p/support/wiki/ConvertingSvnToHg

On Sep 25, 10:38 am, Chris Peters <ch...@clearcrystalmedia.com> wrote:

> I can only offer a few thoughts to this because it seems like we have a
> system that works pretty well with the SVN repository.
>
> I do know that there are some great integration points between the Issues
> and Source sections of Google Code, though I figure that GitHub may very
> well have a similar system. (I'm not too familiar.)
>
> Is there a SVN-to-git migration tool? We have a lot of history stored in our
> SVN repository.
>
> Usage of GitHub would definitely make us appear more hip and snobbish (which
> we should borrow some of the enthusiasm/snobbery from the Rails community,
> IMO... it's the best way to make friends ;)). I'm not sure that that's a
> great reason to switch, but I thought I would throw that out there.
>

[tpet...@gmail.com]

i really don't have any experience with hg, but as i understand it
it's almost the same as git in the sense that it allows for
decentralized collaboration.

if you're familiar with git and hg, could you provide us with some
personal experiencing of using both and why you prefer one over the
other?

in any event, your suggestion is well noted.

[Jeff S.]

I guess my original comment made it sound like I had a strong opinion
on using one over the other. I don't really have any experience with
Git, and minimal experience with Mercurial.

The only reason I threw it out there was because I thought there was a
mention of not wanting to switch entirely away from google code.

Here's some analysis google did on Git vs Mercurial (when they were
deciding which to use):
http://code.google.com/p/support/wiki/DVCSAnalysis

I'm most familiar with SVN, but am going to be using google code's
Mercurial for a few project's soon. I want to check out GitHub as
well though...

[Chris Peters]

Thanks everyone. We've decided to revisit this topic after we release version 1.0 of Wheels. At that point, this will be appropriate to lump in along with conversations like, "How are we going to deal with major and minor releases?"

Until then, it is not worth muddying up our processes while we're working on just shipping the damn thing. ;)