What's hot / growing in Agile

[Glenn Block]

Here's the notes from the what's hot / growing session that we had at the alt.net seattle meeting today.

Tools

                GIT

                CouchDB

                NServiceBus / Mass Transit

                NHibernate

                Selenium

                Rhino Mocks / MoQ, etc

                MSpec

                IoC containers

                Agile Zen

                Version One

 

Methodologies / Principles

                Scrum

                Lean

                TDD

                BDD

                Rx

                DDD

                Dynamic Languages

                Functional Programming

                Fluent Interfaces

                CQS

                Convention over config

                Unobtrusive JS

                Continuous Integration / Continuous Deployment

                Message based apps

Glenn

                

[Roy Osherove]

Thanks Glenn. It sounds like you had some good discussion!

I still see so much emphasis on technology  related tings - and yet one of the things we are missing most is how to be good leaders.

that in itself would help alleviate so many issues to do with agile adoption, the "we don't have that kind of people here" syndrome and the "crappy team lead" syndrome.

another thing missing - the art of influence = that is the thing that will decide exactly how much further agile adoption can go. if we don't know how to influence change then we will always be the "early adopters" and agile, TRUE agile and lean principles, will not cross the chasm into the early and late majority.

In that spirit, I'd love to have any of you submit posts and articles for 5whys.com  - the new website I'm building to help push these things.

just send me an email with post title and text and i'll post it for ya. if all goes well, i'm also welcoming people as full members to blog freely on their own with no supervision on that site.

--

You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group.
To post to this group, send email to altnet...@googlegroups.com.
To unsubscribe from this group, send email to altnetseattl...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.

--
Thanks,

Roy Osherove
www.TypeMock.com - Unit Testing, Plain Smart

Author of "The Art Of Unit Testing" (http://ArtOfUnitTesting.com )
A blog for team leaders: http://5Whys.com
my .NET blog: http://www.ISerializable.com
Twitter: http://twitter.com/RoyOsherove
+972-524-655388 (GMT+2)

[Chris Tavares]

Ok, so I have to ask: why’s everyone getting ga-ga over GIT, instead of one of the other distributed SCMs, particularly when developing on Windows. I’ve at least experimented with Git, Mercurial[0], and Bazaar[2], and GIT is pretty much dead last in usability.

 

Mercurial and Bazaar both treat Windows as a first-class citizen, are easier to use, much less quirky, and you don’t have to use friggen BASH or Cygwin on a Windows box to do useful stuff with it. Mercurial is pretty darn fast, and Bazaar makes it trivial to host read-only repositories on the web (just need straight HTTP, no CGI bin or server support at all).

 

I don’t get why everyone’s so nuts about GIT. What makes it so much better than the others that it’s worth putting up with a all the linuxisms on a windows box?

 

-Chris

 

[0] http://www.selenic.com/mercurial

[1] http://www.bazaar-vcs.org

--

[Kelly Leahy]

one word...  rebase.  As far as I know, none of the other SCMs support it, or at least support it as smoothly as git.

 

I would agree that the usability of git is a bit ridiculous, but I think that's only at first.  Once you've used it for a few days, and if you read the right docs (sometimes hard to find), it doesn't take long before it is obvious that it's a new step forward in version control systems (even though they wouldn't call it such) and that the distributed version control is just the tip of the iceberg, with rebase being the main reason that it is such an amazing VCS.

 

I'm sure this answer is not at all satisfying, but I thought I'd at least chime in with what I had time to say and let some others do the "heavy lifting".

[Ted Neward]

I’ll bite—what do you mean by “rebase”?

 

Ted Neward

Java, .NET, XML Services

Consulting, Teaching, Speaking, Writing

http://www.tedneward.com

[David Foley]

I can't comment on mercurial or bazaar, but I agree that the setup of git on windows is a pain... or at least: the setup & configuration of SSH on windows is kind of a pain. 

Git itself is easy enough to set up... I think? It's been a while and I can't remember, but I don't think it's that difficult. I use the bash/cygwin option, which I like because it's one set of commands to remember cross-platform. 

That said, on OS X, git is dead simple to set up as compared to windows.

The usability of git, once you get past the windows-specific setup problems, is excellent in my opinion. Are there features in bazaar or mercurial (or any other dvcs) that are beyond git's capabilities, other than the windows-antagonism? 

Regarding git-rebase, on my team we basically eschewed it, but I'm curious how other teams are using it...?

[Jason Olson (DPE)]

I’ve been using Mercurial via TortoiseHg (and central via BitBucket). VERY easy to use and I have been loving it. I didn’t experience any of the setup issues I had with git and being first-class on Windows (even Explorer integration) is a definite plus.

 

Jason "For The Developers!" Olson

http://www.managed-world.com

http://twitter.com/jolson88

 

From: altnet...@googlegroups.com [mailto:altnet...@googlegroups.com] On Behalf Of David Foley

Sent: Sunday, December 20, 2009 4:42 AM
To: altnet...@googlegroups.com

[scott...@gmail.com]

Because of github.com.
I don't know of any comparAble site for any other scm. It's so well
done thAt it makes putting up with all the crap in git worthwhile

On Dec 20, 12:10 am, "Chris Tavares" <c...@tavaresstudios.com> wrote:
> Ok, so I have to ask: why's everyone getting ga-ga over GIT, instead of one
> of the other distributed SCMs, particularly when developing on Windows. I've
> at least experimented with Git, Mercurial[0], and Bazaar[2], and GIT is
> pretty much dead last in usability.
>
> Mercurial and Bazaar both treat Windows as a first-class citizen, are easier
> to use, much less quirky, and you don't have to use friggen BASH or Cygwin
> on a Windows box to do useful stuff with it. Mercurial is pretty darn fast,
> and Bazaar makes it trivial to host read-only repositories on the web (just
> need straight HTTP, no CGI bin or server support at all).
>
> I don't get why everyone's so nuts about GIT. What makes it so much better
> than the others that it's worth putting up with a all the linuxisms on a
> windows box?
>
> -Chris
>

> [0]  <http://www.selenic.com/mercurial>http://www.selenic.com/mercurial
>
> [1]  <http://www.bazaar-vcs.org>http://www.bazaar-vcs.org

[Ronald Woan]

I would have thought Cloud platforms and APIs would make the list...

[Chris Bilson]

Advantages of git no one has mentioned yet:

* github

   - it's "cool", somehow

   - ease of forking - I can make speculative changes to a big open source project and even share them with people without bothering the maintainers

   - hosts ruby gems, and since ruby is to .NET developers as "the great american novel they are going to write" is to journalists this appeals to .NET developers pining for ruby. 

       - Imagine if Microsoft could build something like gems for .net/windows, hosted on Codeplex.

* interoperates with other version control systems like svn or cvs

   - I know some people use hg/bzr/git congruently on the same working copy, but git *interoperates* so history flows across

   - I think hg can import from svn, but not maintain a conversation? at least last time I checked...

   - interoperability turns out to be the most important feature when your whole org is not going to switch to DVCS at once

* What does the VCS really need windows for anyway? 

   - For typing in commit messages? SET EDITOR=notepad++. 

   - Merging? git config --global --replace diff.tool BComp.exe (or whatever diff tool you like)

   - Seeing history? gitk, qgit...

   - There are also some really neat tools built into emacs (egg-mode, magit). I bet the same thing exists for vim users too.

   - It's easy to write powershell/bash/cmd scripts that automate things in git so you don't even see it the majority of the time, if that helps.

What are the linux-isms you mentioned? Is it just msys and bash that is bothering you? I usually use git from powershell (with a bunch of aliases and special functions) so this doesn't bother me (not that bash would bother me anyway, just that I don't need to leave powershell.)

The real weakness of git on windows, IMO, - and this could be considered a linux-ism, I guess - is the reliance on fast process spawning. Git is composed of a bunch of little tools, and on unix, where forking a process is about as fast as CreateThread is on windows, this is fine, but on windows it blows, and makes git kind of slow on windows...or slower than it could be, anyway.

It seems like hg and bzr have some advantages over git, but git won. Even the python guys know this.

--c

[Chris Bilson]

We did mention this, but Glenn was looking more for specific tools and practices, I think. To me, Cloud Computing is a _force_ pushing us to adopt certain tools and practices (like SOA, message based architectures, etc.)

--c

On Sun, Dec 20, 2009 at 07:58, Ronald Woan <rsw...@gmail.com> wrote:

I would have thought Cloud platforms and APIs would make the list...

[Charlie Poole]

Hi Scott,

> Because of github.com.
> I don't know of any comparAble site for any other scm. It's
> so well done thAt it makes putting up with all the crap in
> git worthwhile

Have you looked at Launchpad.net? I'm quite happy with it - and
with Bazaar. I've now moved five different NUnit-related projects
there. Unfortunately, I don't know enough about github to make
comparisons.

Charlie

[Jason Olson (DPE)]

Really? Perhaps I'm ignorant, but why isn't Bit Bucket on par with Github?

Jason "For The Developers!" Olson
http://www.managed-world.com
http://twitter.com/jolson88

[Charlie Poole]

Hi Chris,

 

Good! A list of features, so I can lay in my experience on Launchpad as a comparison. :-)

* github

   - it's "cool", somehow 

Same with LP, but that's probably in the eye of the beholder. :-) 

   - ease of forking - I can make speculative changes to a big open source project and even share them with people without bothering the maintainers 

Yup. This is the main thing that attracted me to Lauchpad in the first place.

   - hosts ruby gems, and since ruby is to .NET developers as "the great american novel they are going to write" is to journalists this appeals to .NET developers pining for ruby.  

There's no particular relation of LP to any language, although there is Ruby stuff up there. I may not be understanding since I'm more into Python currently than Ruby. 

       - Imagine if Microsoft could build something like gems for .net/windows, hosted on Codeplex.  

 Please... not on Codeplex! and not Microsoft! We need a community site. 

 

 * interoperates with other version control systems like svn or cvs  

   - I know some people use hg/bzr/git congruently on the same working copy, but git *interoperates* so history flows across 

That's a git (not github) feature. Bazaar interoperates the same way with svn and (I've heard) hg. Not CVS, however, but that isn't a really big loss for new projects. 

   - I think hg can import from svn, but not maintain a conversation? at least last time I checked...

   - interoperability turns out to be the most important feature when your whole org is not going to switch to DVCS at once

* What does the VCS really need windows for anyway? 

   - For typing in commit messages? SET EDITOR=notepad++. 

   - Merging? git config --global --replace diff.tool BComp.exe (or whatever diff tool you like)

   - Seeing history? gitk, qgit... 

I find it the same with bzr, since I'm more of a command-line guy. I think that some folks mean command line when they say "linux-like" but as you know, Windows has one as well. :-)  However, if one prefers a gui, there's TortoiseBzr as well as Explorer integration.

   - There are also some really neat tools built into emacs (egg-mode, magit). I bet the same thing exists for vim users too.

   - It's easy to write powershell/bash/cmd scripts that automate things in git so you don't even see it the majority of the time, if that helps.  

 I haven't needed this so far. I just use the bzr commands and extensions - which look just like commands.

 

What are the linux-isms you mentioned? Is it just msys and bash that is bothering you? I usually use git from powershell (with a bunch of aliases and special functions) so this doesn't bother me (not that bash would bother me anyway, just that I don't need to leave powershell.)

The real weakness of git on windows, IMO, - and this could be considered a linux-ism, I guess - is the reliance on fast process spawning. Git is composed of a bunch of little tools, and on unix, where forking a process is about as fast as CreateThread is on windows, this is fine, but on windows it blows, and makes git kind of slow on windows...or slower than it could be, anyway. 

 

I've found bzr to be quite fast, even when used with a remote repository. It's even faster when you set up a local mirror of the project trunk and branch locally.

It seems like hg and bzr have some advantages over git, but git won. Even the python guys know this.

Launchpad has a ton of Python projects. In fact, it *is* a Python project - and Launchpad itself has Python bindings for those who want to do automation.

 

Either github didn't exist or I just didn't know about it when I discovered Launchpad a few years ago. I suspect that each of them has areas that are better and others that are not as good yet. But I don't have any buyer's remorse about my decision to go with Lauchpad. Anybody who is looking to go distributed should probably look closely at both of them today.

 

Charlie

[Ronald Woan]

I might toss Google App Engine, Amazon EC2, and Azure APIs in the hat
then as specific instances...

[Ronald Woan]

Fog Creek is now offering hosted Mercurial as well:

http://fogcreek.com/kiln/

On Dec 20, 11:48 am, "Jason Olson (DPE)" <Jason.Ol...@microsoft.com>
wrote:

[Chris Bilson]

Wow, that looks interesting. I wonder how much it will cost. Are you on the beta program? Thanks for the link.

--c

--

[Chris Bilson]

Good point. I'd also add force.com. That's what our management is really interested in right now.

--c

--

[Jason Olson (DPE)]

Mercurial hosting is also offered by Google Code and Project Kenai (Sun), I believe.

Jason "For The Developers!" Olson
http://www.managed-world.com
http://twitter.com/jolson88

-----Original Message-----
From: altnet...@googlegroups.com [mailto:altnet...@googlegroups.com] On Behalf Of Ronald Woan
Sent: Sunday, December 20, 2009 9:24 AM
To: Seattle area Alt.Net
Subject: Re: What's up with GIT? (was: RE: What's hot / growing in Agile)

http://fogcreek.com/kiln/

--

[Chris Bilson]

Thanks Charlie.

* github

   - it's "cool", somehow 

Same with LP, but that's probably in the eye of the beholder. :-) 

Agreed. I am actually extra skeptical of things that are cool, but github seems to have passed that screen for me, as I'm sure LP would as well.

   - ease of forking - I can make speculative changes to a big open source project and even share them with people without bothering the maintainers 

Yup. This is the main thing that attracted me to Lauchpad in the first place.

I will go look later, but do you, as a project maintainer get good visibility as to what different forks are doing? 

 

   - hosts ruby gems, and since ruby is to .NET developers as "the great american novel they are going to write" is to journalists this appeals to .NET developers pining for ruby.  

There's no particular relation of LP to any language, although there is Ruby stuff up there. I may not be understanding since I'm more into Python currently than Ruby. 

I'm not really a ruby person either, but the ease with which I can install gems or rails plugins straight off of github makes my blood race a little...and I'm a little jealous.

 

       - Imagine if Microsoft could build something like gems for .net/windows, hosted on Codeplex.  

 Please... not on Codeplex! and not Microsoft! We need a community site. 

Codeplex is already there. Microsoft seems to have lots of people with time on their hands working on less useful things (MSTest?) Maybe those guys could build something like gems for .net instead? I wish I had time and energy to do it.

Do you mean a community site on par with github/launchpad (i.e. a host for gems) or a community _project_ to build something like gems? 

I think the horn project endeavors to be like the latter. It's been a while since I've looked at it and they seem to have made some progress and gotten some buy in from the Castle project (no source - can't remember where I read that.)

  * interoperates with other version control systems like svn or cvs  

   - I know some people use hg/bzr/git congruently on the same working copy, but git *interoperates* so history flows across 

That's a git (not github) feature. Bazaar interoperates the same way with svn and (I've heard) hg. Not CVS, however, but that isn't a really big loss for new projects. 

Yes, a git feature. I wasn't aware that Bazaar's interaction with subversion was two-way. 

I think I will continue to use git and don't have any major problems with it. I've used hg and bzr to get other peoples code and it doesn't seem like I would have any major problems with them either. I think this is just one of those things where we should be thankful we have so many wonderful choices.

--c

[Lee Fisher]

> I don�t get why everyone�s so nuts about GIT. What makes it so much
better
> than the others that it�s worth putting up with a all the linuxisms on a
> windows box?

Like someone already set, GitHub is one reason. Android is also probably
a driver of usage. Integration with SVN might be another.

Git's distributed nature is great, if you've not already got hooked on
another distributed SCM. It grows on you quickly, if you use it with an
open mind.

Git does not require CygWin/Bash, there's also a MinGW-compiled version[1] .

For more "windowsisms", you can wrap a GIT#[2] into a PowerShell script
and and write bash-free advanced scripts. Or use a GUI with Explorer and
VS integration[3].

[1] <http://code.google.com/p/msysgit/>
[2] <http://www.eqqon.com/index.php/GitSharp>,
<http://github.com/henon/GitSharp>, <http://github.com/pheew/dotgit>
[3] <http://code.google.com/p/gitextensions/>,
<http://code.google.com/p/tortoisegit/>

[Kelly Leahy]

rebase is the ability to "reapply" history in a different order, it allows you to basically rewrite your local history.  You should NEVER do this with history that's already been "shared" with others, but it works very well within my workflow, and I suspect the workflows of others.

 

so, for instance, let's say I'm working on feature A and feature B simultaneously - this happens a lot with my work where feature A and feature B are related enough that it makes sense to work on them on the same day and not release either until both are finished.

 

So, I start with A, do some checkins (locally) - A.1, A.2

 

Then, I do some work on B, checking in B.1

 

Now, in the process of doing B.1, I find some bugs with A and fix them in A.3. 

 

Then, I return to B.2, B.3.

 

Now, I'm done for the day, so I'm ready to checkin.  My history looks like (in reverse order):

B.3

B.2

A.3

B.1

A.2

A.1

 

optimally, I'd like my history to look like:

B

A

 

since I haven't pushed any of these changes or shared them with others, I do a:

git rebase -i HEAD~6

 

and reorder the commits to be A's first, then B's, and mark the "extra" A's and B's as being 'squashed'.  Git will combine the commits and reorder them (automatically), and almost never will any merging be needed (on the user's part), and then ask you what the new two commits should be called.

 

Then, once you're done you can push changes to others on your team and they'll see the "new" history.

 

Also, once you get to know Git a bit, you can very easily "rewrite" history, move your checkins around, rollback to previous HEADs, etc., which are pretty advanced topics, but if used properly (only on local changes that haven't been pushed) can allow you to do some really amazing things that can save you an extraordinary amount of time.

 

BTW, the use case I described above is only one of the cases where 'rebase' is used.  There are also some really nice things in git that are done with rebase behind the scenes.  One of them I really like is when you're in the 'centralized repo' model, and you want to do a 'pull' from the remote repo, git can do that in two different ways.  One of them is to "merge" the changes from the remote repo into your local repo (using a merge if fast-forward isn't possible), meaning that the changes from the remote repo will show up "after" your changes that you've performed locally.  However, most of the time, you'd probably prefer that the pulled changelists show up "before" your currently unpushed local changes.  That way your "unpushed" changes are always "next to be pushed", no matter how many pulls you do.  This is definitely how I do my pulls, and is done by a "git pull --rebase".

 

Kelly

[Chris Tavares]

On the general “github is unique” meme … well, it isn’t. bitbucket.org is pretty much an exact clone of github for mercurial, and launchpad.net has what I think is the equivalent feature set for bazaar.

 

The rebase thing is interesting, and I will freely admit I don’t get it, but I suspect that’s because I’ve never had the problems that rebase is intended to solve. What’s the problem it’s actually solving?

 

I picked up the O’Reilly book on Git about two months ago, and I remember it spent the first chapter crowing about how history in Git is immutable for all time and how important it was. Then it seemed to spend the rest of the book talking about how to change that history. Kinda confused me. J

 

-Chris

 

 

From: altnet...@googlegroups.com [mailto:altnet...@googlegroups.com] On Behalf Of Kelly Leahy

Sent: Sunday, December 20, 2009 12:16 AM
To: altnet...@googlegroups.com

[Lee Fisher]

> I picked up the O'Reilly book on Git about two months ago, and I
remember it
> spent the first chapter crowing about how history in Git is immutable for
> all time and how important it was. Then it seemed to spend the rest
of the
> book talking about how to change that history. Kinda confused me. J

An alternative, the [free] Git Community Book:

http://book.git-scm.com/
http://book.git-scm.com/book.pdf

eg:
http://book.git-scm.com/4_rebasing.html

[Kelly Leahy]

Chris,

 

I think I can help clear up some of that confusion.  When they talk about "immutable history", they mean that each checkin CANNOT be changed EVER from now until the end of time.  However, since git is simply a DAG, you can remove nodes from the DAG and replace them with other nodes.  That's how you "change" history.  You're not changing the individual commits in the history, you're just replacing them with other commits.

 

As for the reason for rebase, I tried to give my example of why I use it - and I find it to be extremely useful both in the 'put my stuff last after a pull' and the 'reorder / squash my local commits into a much more coherent history' use cases.  That said, others may say something like "I don't really look at history much, so I don't really care..." (in fact, I said this myself a few months ago at ALT.NET and have changed my mind since).

 

I think the key selling points for git for me are:

1) rebase

2) low friction (I think most VCSs starting to go this way - where they "detect" changes instead of forcing you to identify them like P4 does)

3) speed (particularly with branching)

4) really incredible ability to manipulate the history, head, etc. very easily (once you understand it)

5) critical mass (there are now enough people using it that it's pretty easy to find information on it when you need it)

 

For me, github, etc. are of no value whatsoever in the "reasons I use git", nor is cross-platform support, etc.  For me, the ONLY real reason that I would switch to git is rebase (from svn, for instance).

 

I can also say that I think one of the major reasons git is getting so much adoption is because of the bridges between it an other VCS.  For instance, we use P4 for one of our projects at the office.  I now completely use git for that project and then only push things to p4 using git-p4.  I can do all my work without the friction of P4, while not forcing the other people on the team to move to git or taking the effort to "migrate" the repo to git.

 

We did the same thing with svn.  The way we started working in git was that Justin Bozonier (on this list, and on my team) took the initiative to start working with git, while we had just recently switched from p4 to svn for our source control.  He was using the git svn integration, and learned quite a bit about git and decided he liked it.  Then, after he was "sold", I looked into it, and HATED it.  I put it aside for a while, and several months later the conversation came up again, I tried it again, and HATED it again (for another week).  Then, after a week of forcing myself to use it, I got past the fact that I needed to use bash, etc. and started to realize how quickly I could do work.  After 2 weeks of using it, I absolutely fell in love, and now we've migrated our svn repo to git and are using "pure git" for our version control.  Now, I'm pretty much in love with git.

[Justin Rudd]

Just so BitBucket/Mercurial doesn't get completely ignored :)

* github and LaunchPad - ease of forking

Mercurial has BitBucket which has the one click forking just like GitHub.  So you can see who has forked your project, what they've done to it, etc.  

A couple of bonus features for me - the wiki is just another Mercurial repository.  And CNAME was much easier to setup than GitHub.

* hosted RubyGems

No more gems on GitHub.  They've told everyone to move to GemCutter (http://github.com/blog/515-gem-building-is-defunct).  But the main point is sound.  Gems are nice (except when they aren't :) which is more the fault of the gem packager than gem system)  Thanks for the pointer to horn.  Hadn't seen that before.

* Interopt with SVN

hgsvn is new set of tools that are like git-svn.  They are new, but they work pretty well.  I've not used it extensively.  But on a few of the Google Code projects I pulled in, it works great.

But I agree with you.  Git works well for you because you've devoted the time to learning it.  Mercurial works best for me because that's where I've spent my time.  I know enough git that I can use it.  The same as bazaar and darcs.

Justin

--

[Erick Thompson]

Thanks Glenn, this was a great discussion. I saw the other thread on GIT - it looks like I have some good xmas reading to do!

 

Erick

[Erick Thompson]

Ok, so aside from the benefits of a distributed SC in terms of performance, why would someone (i.e., me) move from VisualSVN/Tortise to Git?

 

Thanks,

Erick

[Justin Rudd]

http://git.or.cz/gitwiki/GitSvnComparsion

Obviously biased since it is written by the git maintainers :)

A couple of things on there that I've found very useful (even though I use Mercurial)...

Distributed Nature - the multiple copies and full local history (although they may all be at different heads) are very useful.  Just witness in the Ruby world when _why disappeared.  Had he been running SVN all you'd have is whatever someone last sync'ed to + their revisions.  It would have been painful to piece together from checked out repositories in SVN.  With git, people just started merging from the last known good tip.

Speed - everything is local.  Branching, merging, etc. all local.  Only fetch and push require network access.  If you are dealing with a distributed team with a spotty wan, this is a godsend.

The main downside (in my opinion) is that GUI tools are emerging.  Now for developers, GUI tools aren't required (usually).  But if your documentation is being stored in SCM, I've found that getting my writers to use git is harder than Subversion.  Maybe TortoiseGit will change that, but it is pretty easy to tell people "When the icon is red, right click, and select commit".  For git, commit means local commit, then they have to choose push, etc.

If you have time, you can write scripts they can use to hide these details.  With libraries like SharpSVN or Git#, your writers would never know (in theory).

Justin

[Charlie Poole]

Hi Chris,

   - ease of forking - I can make speculative changes to a big open source project and even share them with people without bothering the maintainers 

Yup. This is the main thing that attracted me to Lauchpad in the first place.

I will go look later, but do you, as a project maintainer get good visibility as to what different forks are doing? 

 

Sure. All public branches of a project are tracked by launchpad and can be listed, viewed, downloaded, etc. Folks can propose their branch for merging into the official project trunk, in which case there's a review process available. The actual merge can be done manually (merge into a local branch, run tests, push) or using several different automated tools that use the Launchpad api.

       - Imagine if Microsoft could build something like gems for .net/windows, hosted on Codeplex.  

 Please... not on Codeplex! and not Microsoft! We need a community site. 

Codeplex is already there. Microsoft seems to have lots of people with time on their hands working on less useful things (MSTest?) Maybe those guys could build something like gems for .net instead? I wish I had time and energy to do it.

Do you mean a community site on par with github/launchpad (i.e. a host for gems) or a community _project_ to build something like gems?  

 

The latter. 

I think the horn project endeavors to be like the latter. It's been a while since I've looked at it and they seem to have made some progress and gotten some buy in from the Castle project (no source - can't remember where I read that.)

  * interoperates with other version control systems like svn or cvs  

   - I know some people use hg/bzr/git congruently on the same working copy, but git *interoperates* so history flows across 

That's a git (not github) feature. Bazaar interoperates the same way with svn and (I've heard) hg. Not CVS, however, but that isn't a really big loss for new projects. 

Yes, a git feature. I wasn't aware that Bazaar's interaction with subversion was two-way.  

 

There's a bzr-svn extension that allows working with an svn repository as if it were in bzr. That allows you to create a local mirror of trunk for an svn-hosted project, create local feature branches, code in them and then push them back to the project (if you're a committer) or create a patch and send it to the project. 

I think I will continue to use git and don't have any major problems with it. I've used hg and bzr to get other peoples code and it doesn't seem like I would have any major problems with them either. I think this is just one of those things where we should be thankful we have so many wonderful choices. 

 

Yup. 

 

Charlie 

--c

[Bobby Johnson]

The biggest advantage to me for Git over SVN is it moves the checkin/branching dance locally. I can have long running conversations with source control locally and then merge/commit to the server when I am ready.

I cannot count the number of times I have gotten latest form source control, worked for several hours and came to a point where I didn't like where I was and reverted using SVN.

With git I commit locally a lot more often because its so cheap and fast. I create branches for EVERYTHING because its cheap and fast. Those branches can live for weeks at a time with out using server resources or impacting the team in any way.

My daily workflow looks something like this http://gist.github.com/249074

"The explanation requiring the fewest assumptions is most likely to be correct."

- Occam’s Razor
http://en.wikipedia.org/wiki/Occam's_Razor

[Josh Coffman]

I have to admit I was slightly skeptical and confused by git when I first started learning about it.  Now, I'd definitely prefer it over any other SCM that I know.  It's fast, merging in painless 99.99% of the time, and everything Bobby just said too.

Josh C.
480-270-4578 | josh [at] computeristsolutions [dot] com | http://computeristsolutions.com

[Glenn Block]

Thanks Roy

the topic was centered specifxally around tools and methodologies as
It relates to agile. It is for an upcoming presentation to the
developer division.

On Saturday, December 19, 2009, Roy Osherove <royos...@gmail.com> wrote:
> Thanks Glenn. It sounds like you had some good discussion!
> I still see so much emphasis on technology  related tings - and yet one of the things we are missing most is how to be good leaders.
> that in itself would help alleviate so many issues to do with agile adoption, the "we don't have that kind of people here" syndrome and the "crappy team lead" syndrome.another thing missing - the art of influence = that is the thing that will decide exactly how much further agile adoption can go. if we don't know how to influence change then we will always be the "early adopters" and agile, TRUE agile and lean principles, will not cross the chasm into the early and late majority.
>
> In that spirit, I'd love to have any of you submit posts and articles for 5whys.com  - the new website I'm building to help push these things.just send me an email with post title and text and i'll post it for ya. if all goes well, i'm also welcoming people as full members to blog freely on their own with no supervision on that site.

>
>
>
>
> On Sun, Dec 20, 2009 at 9:23 AM, Glenn Block <glenn...@gmail.com> wrote:
>
> Here's the notes from the what's hot / growing session that we had at the alt.net seattle meeting today.
> Tools                GIT
>                 CouchDB
>                 NServiceBus / Mass Transit                NHibernate                Selenium                Rhino Mocks / MoQ, etc                MSpec                IoC containers
>
>                 Agile Zen                Version One
>
> Methodologies / Principles                Scrum                Lean
>
>                 TDD                BDD                Rx                DDD                Dynamic Languages                Functional Programming                Fluent Interfaces
>
>                 CQS                Convention over config                Unobtrusive JS                Continuous Integration / Continuous Deployment                Message based apps
>
>
> Glenn
>
>
>
>
>

> --
>
> You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group.
> To post to this group, send email to altnet...@googlegroups.com.
> To unsubscribe from this group, send email to altnetseattl...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.
>
>
> --

> Thanks,
>
> Roy Osherove
> www.TypeMock.com - Unit Testing, Plain Smart
>
> Author of "The Art Of Unit Testing" (http://ArtOfUnitTesting.com )
> A blog for team leaders: http://5Whys.com
> my .NET blog: http://www.ISerializable.com
> Twitter: http://twitter.com/RoyOsherove
> +972-524-655388 (GMT+2)

[Glenn Block]

Is that specifically related to agile though?

On Sunday, December 20, 2009, Ronald Woan <rsw...@gmail.com> wrote:
> I would have thought Cloud platforms and APIs would make the list...
>

[Glenn Block]

I agree that the initial getting up and running phase of git is less
than to be desired. For me gothic is one big advantage as well as all
the patching support. Have not played with mercuial yet, but plan to.

On Sunday, December 20, 2009, Chris Tavares <c...@tavaresstudios.com> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
> Ok, so I have to ask: why’s everyone getting ga-ga over
> GIT, instead of one of the other distributed SCMs, particularly when developing
> on Windows. I’ve at least experimented with Git, Mercurial[0], and Bazaar[2],
> and GIT is pretty much dead last in usability.
>
>
>
> Mercurial and Bazaar both treat Windows as a first-class
> citizen, are easier to use, much less quirky, and you don’t have to use
> friggen BASH or Cygwin on a Windows box to do useful stuff with it. Mercurial
> is pretty darn fast, and Bazaar makes it trivial to host read-only repositories
> on the web (just need straight HTTP, no CGI bin or server support at all).
>
>
>
> I don’t get why everyone’s so nuts about GIT. What
> makes it so much better than the others that it’s worth putting up with a
> all the linuxisms on a windows box?
>
>
>
> -Chris
>
>
>
> [0] http://www.selenic.com/mercurial
>
> [1] http://www.bazaar-vcs.org
>
>
>
>
>
>
>
> From:
> altnet...@googlegroups.com [mailto:altnet...@googlegroups.com] On
> Behalf Of Glenn Block
> Sent: Saturday, December 19, 2009 11:23 PM
> To: altnet...@googlegroups.com
> Subject: What's hot / growing in Agile
>
>
>
>
>

[Justin Rudd]

I think so.  Well...in Google App Engine's case (and maybe Azure).  With AppEngine, I write my code (albeit in Python or Java) and push.  AppEngine takes care of spikes in traffic, storage, etc.  It is the ultimate black box.  I do have to deal with indices and what not, but no networking, no spinning up of new instances, etc.  With Amazon EC2, I have to spin up my own instances, get them behind a load balancer, etc.  Or write software that does that for me.  With Azure, I believe I have to do similar things - I have to add new instances (web or worker), but don't have to put behind load balancer, etc.

So with AppEngine - agile because all I have to worry about is my code and pushing it.  AppEngine takes care of the rest.  Azure mostly agile.  EC2, IMO, somewhat agile if you have the hooks in place to know what's going on in your system.

[Glenn Block]

Awesome thread guys, this is why I love this list as er opposed to the
'other' one that shall remain nameless.

[Glenn Block]

Ok, but I am guessing with the prevalence of app engine, the division
will have heard of it :-). I will add it though.

Thanks

[Ted Neward]

My main working theory (since I haven’t had the time to test this in practice yet) is that a distributed SCM is going to make it easier for me to push/manage code across several different machines/environments (such as the half-dozen or so virtual machines I work in), particularly as then I can have a repo on a machine at home that I can push to every so often as a kind of backup, and then have a “public” repo somewhere that other people can pull from (for things like presentations and sample code, for example).

 

But since this list has folks on it who are more distributed SCM savvy than I, does that theory make sense? Any obvious tripping-up factors? And while I’m trolling for thoughts, do any of these have better or worse reactions to “binary” files (like PPTs and DOCs and PDFs)? Anybody know a good “Mercurial eye for the SVN guy” book or resource?

 

Personally I’m more inclined towards Mercurial than git for the Windows-centric reasons mentioned before, but my hg-fu is only slightly better than my git-fu, both of which are pretty weak. One of my goals for 2010 is to convert my SVN repo over to a distributed repo, but I doubt I’m going to see the benefits of a distributed SCM on my little indie projects. :-)

 

Ted Neward

Java, .NET, XML Services

Consulting, Teaching, Speaking, Writing

http://www.tedneward.com

 

 

From: altnet...@googlegroups.com [mailto:altnet...@googlegroups.com] On Behalf Of Erick Thompson
Sent: Sunday, December 20, 2009 5:01 PM
To: altnet...@googlegroups.com
Subject: Re: What's up with GIT?

 

Ok, so aside from the benefits of a distributed SC in terms of performance, why would someone (i.e., me) move from VisualSVN/Tortise to Git?

[Josh Coffman]

Ted,

  Your theory works in practice.  I have a mix of real and virtual machines which I code on and pull from various git repositories including github and unfuddle.  being able to do that so easily has really been a big selling point for me on git.  I tried one other dscm and it was just fine, but went with the more common dscm.

-j

Josh C.
480-270-4578 | josh [at] computeristsolutions [dot] com | http://computeristsolutions.com

[Justin Rudd]

Your theory is sound.  I pretty much do what you describe.  I have a master mercurial repository on a server somewhere.  This master repository usually gets pushed up to a central repository (running on Vault) whenever major functionality has been completed.  I've got an every 4 hour cron that pulls from Vault to make sure I'm up-to-date.  Since I'm on the only one on the Vault repo right now, it isn't strictly necessary.

I'll clone off this master repository onto my dev desktop.  When I get tired of sitting at home, I'll clone the repository to my laptop, go to the coffee shop, hack a bit, and come home.  I'll then push from the laptop back to my desktop.  I've got a few virtual machines for different windows versions that I test on.  I'll start one up, pull from my dev box repo, build, and test.  Any changes that I make during testing on that OS, I'll make right there and push back to my dev repo when testing complete.

My main goal right now is to figure out how to automate a lot of this stuff.  9 times out of 10, on the virtual machine, I pull, build, and test and everything passes.  I'd like to reduce the manual aspects of it, but just haven't hit that frustration factor yet.  I'm open to suggestions here :)

As for binary files, Mercurial complains when it is over 10MB.  It is just a warning.  I've stored 70MB binaries just fine.  I've never had any problems with assemblies or jar files.

[Chris Tavares]

I’ve been doing this with Bazaar for a while, actually. When I wrote my MVC article, I included a (pretty trivial, really) wiki as a sample. That was written against the first release of the MVC framework, so it needed regular updates as the framework progressed, and I needed an easy way to get it out to people.

 

So what I did was push my repository to my web host over FTP. Now, anyone can get to it over HTTP[0], and more importantly I can work on it anywhere: home, work, on a bus, etc. Then just push back up to the web server whenever I want. Anyone else can branch my repo if they want as well, and are free to send me change sets if they want for me to integrate back into the “master” repo.

 

I’ve since played with Mercurial a little more and think it’s a little better than Bazaar, but bzr has the advantage that all you need to get a public read-only repository is a plain HTTP server. No server side component required at all. For something bigger I’d probably still use a hosting service like bitbucket or launchpad, but for what I wanted and simplicity it was a big win.

 

-Chris

 

[0] To branch my repo, you’d do bzr branch http://www.tavaresstudios.com/branches.ashx/MiniWikiMain

 

[1] Ok, I lied – you need a little bit of server side help on IIS because there’s a couple files in the BZR repo that don’t have any extensions, so IIS won’t serve them up. Luckily it was easy to fix with a quick ashx page. With other servers there’s nothing of the sort required.

[Charlie Poole]

Hi Ted,

 

That's been my experience. The key drawback I've seen is that (as with anything)

you can overdo it. I've found myself once or twice with too many threads of work

going on at the same time and have had to discipline myself to keep my own

personal capacity for branching in mind. But it's invaluable to me both for my

own work and for trying out patches provided by other people.

 

My own general approach (using Bazaar and Launchpad) is as follows:

 

1) A local trunk branch on each machine is kept up to date with the "official" trunk

on Launchpad by periodically pulling from it. I don't make changes or even build

in this branch.

 

2) For discrete pieces of work, I'll branch from the local trunk, code and do

local commits until I'm ready to release.

 

3) For non-trivial changes, I'll push the local feature branch to a public branch

on Launchpad for review. Depending on the review, I may repeat steps 2 &  3

several times.

 

4) Once the branch is approved, I push the changes again, but this time to

the public trunk. (Trivial changes skip step 3 and I do this directly.)

 

5) My local mirror of trunk gets updated automatically the next time I pull

from it. This spreads the change to all my machines as well.

 

6) As changes to trunk are made, I merge them with any ongoing work

in other branches at whatever point is convenient.

 

Working this way, the majority of my branches and all my merges are

entirely local. This is particularly convenient when I'm using my laptop

while travelling or in my favorite (non-connected) coffee shop.

 

Charlie

 

PS: I've written some instructions for NUnit contributors in how to set up

their working copy. Here's a link, in hope it may be helpful for others...

http://nunit.org/wiki/doku.php?id=dev:faq:working_copy

---

From: altnet...@googlegroups.com [mailto:altnet...@googlegroups.com] On Behalf Of Ted Neward
Sent: Monday, December 21, 2009 6:38 PM
To: altnet...@googlegroups.com

Subject: RE: What's up with GIT?

[Gary Bernhardt]

On Dec 20, 12:16 am, Kelly Leahy <kelly.p.le...@gmail.com> wrote:
> one word...  rebase.  As far as I know, none of the other SCMs support it,
> or at least support it as smoothly as git.

People who have only (or mostly) used git seem to say this a lot. It's
not true! :) The obvious counterexample is mercurial's "rebase"
extension, which is included in the distribution. There's also
histedit, which does exactly what git's "rebase -i" does, even using
the exact same syntax when editing the history.

Git's rebase is not the ultimate, unquestionable solution for commit
rearranging. People seem to discover it first, then latch onto it for
some reason. Mercurial's mq extension (mercurial patch queues), for
example, is *more powerful* than git rebase, including git rebase -i,
yet much easier to use. It's existed for several years and comes with
hg, although it's turned off by default. If you spend the time to
learn it, it will explode your brain and make all other version
control systems look like toys. :)

--
Gary
http://blog.extracheese.org

[Charlie Poole]

Hi Gary,

Thanks for this, as I missed seeing the original post...

> On Dec 20, 12:16 am, Kelly Leahy <kelly.p.le...@gmail.com> wrote:
> > one word...  rebase.  As far as I know, none of the other
> SCMs support
> > it, or at least support it as smoothly as git.
>
> People who have only (or mostly) used git seem to say this a
> lot. It's not true! :) The obvious counterexample is
> mercurial's "rebase"

...

Yes, in general there's a lot of that about tools. I suppose
it's based on someone having a less deep knowledge of the
tools they are not using. At the extreme, folks tend to
compare the tool they are using regularly with one for
which they read the feature list a few years back. :-(

For the sake of completeness, I'll note that in bazaar the
equivalent command is also called "rebase" and is part of the
"rebase" extension. It seems to do everything I need to do,
but other tools may do things for which I haven't yet
discovered the need. :-)

Charlie

Charlie

[Kelly Leahy]

Thanks Gary,

 

I was certainly not trying to misrepresent anything.  Choice of tools is almost always more about personal preference and timing than it is about feature sets, so I'm not surprised that I don't know much about hg or the other tools out there - it was just a matter of timing that we ended up with git, and all the statements I made about other SCMs were based on what I've heard from other individuals.  I thought this was clear (that I wasn't sure about support of these features in other SCMs) but if it wasn't, I apologize.

 

Kelly

[Gary Bernhardt]

Understood; I hope my email didn't come across as a personal
accusation. My broad statement about "people who have only (or mostly)
used git" was a genuine, foolhardy generalization. :)

The git world is quite an echo chamber right now, and has been for
some time. It seems to have been fueled primarily by the Ruby world's
sudden infatuation with the tool. I'm on a bit of a crusade to slay
the various echo chambers of the Ruby world. :)

--
Gary
http://blog.extracheese.org

[Kelly Leahy]

No worries... didn't sound like an accusation to me...  I just wanted to clarify that I was only stating what I know about git, not anything in particular about other SCMs.  I probably should have left out the part about not thinking that other SCMs could do rebase.  I'll be curious to see where the conversation goes around git vs. mercurial vs. etc...  Personally, I just want our work to be as efficient as possible and git put us much closer to that than svn, so that's why we love git.  We would probably love mercurial just as much - but the hype around git led us to believe that it's getting better adoption and so that's the tool we looked at.  Wrong or right, that's the way the world works :)

 

Kelly

[David Foley]

It seems like the big jump is from server-based VCS to distributed, regardless of the particular DVCS.

[scott...@gmail.com]

OK, I signed up for launchpad and started looking around. Again, I'm
comparing it to GitHub not because I think that Git is particularly
well designed, but because I think GitHub is the primary reason there
is a TON of interest in Git. I think if you could use Bazzar with
GitHub, Bazzar usage would take off as well.

I looked at what I thought would be two fairly popular project pages
on each site. Gnome Do for launchpad.net (https://launchpad.net/do)
and Rails for Github (http://github.com/rails/rails).

Right away the differences in design are striking. The launchpad.net
page is a wall of text links.
I tried to find the 'Watch" feature that I use all the time in GitHub,
the feature posts updates made to the project to your dashboard, but I
was unable to find any. The best I could find was a "subscribe to bug
emails" link? I tried 3 other projects just to make sure that the
project page design was consistent at launchpad and it is.

so I looked at BitBucket and found it to be an, almost, exact GitHub
clone. With the main difference being that my dashboard doesn't show
the latest changes to the projects I'm following, but shows all of the
public changes. Which is less useful than github. One other thing
BitBucket was missing was the "Explore" functionality. It has a search
function, but no way, that I could find, to see what projects have
been forked/watched the most. That helps if you want to go where the
crowd is. Being able to drill down by language used is also useful.

I'm certainly not going to deny that launchpad.net and BitBucket
aren't useful sites for some people or deride anyone for using them.
I've already found a couple of projects on each that I'm interested in
following. Just saying that the design of Github, combined with a lot
of big named projects deciding to use it, is probably what is driving
the massive interest in Git.

[Charlie Poole]

Hi Scott,

> OK, I signed up for launchpad and started looking around.
> Again, I'm comparing it to GitHub not because I think that
> Git is particularly well designed, but because I think GitHub
> is the primary reason there is a TON of interest in Git. I
> think if you could use Bazzar with GitHub, Bazzar usage would
> take off as well.
>
> I looked at what I thought would be two fairly popular
> project pages on each site. Gnome Do for launchpad.net
> (https://launchpad.net/do) and Rails for Github
> (http://github.com/rails/rails).

The first link is for the main project page for gnome do.
the source code is at https://code.launchpad.net/do which
seems to be a better content match for the rails url.

>
> Right away the differences in design are striking. The
> launchpad.net page is a wall of text links.

To be honest, I can't see much difference in design between
the two. Sure, the details are different but they are both
pretty busy pages. I think you have to understand the structure
of launchpad or github pretty well to find your way around them.

I'm not trying to say one or the other is better, just that it's
very much in the eye of the beholder and that - once you get
used ot a particular site - othes seem "wrong" if they are
different.

> I tried to find the 'Watch" feature that I use all the time
> in GitHub, the feature posts updates made to the project to
> your dashboard, but I was unable to find any. The best I
> could find was a "subscribe to bug emails" link? I tried 3
> other projects just to make sure that the project page design
> was consistent at launchpad and it is.

Does "Watch" track everything? LP lets you subscribe to bugs,
to branches, to questions, etc. - so it both allows and requires
you to make selections at a fairly detailed level.

That's fine for me because I use LP to host projects. I almost
never browse or explore any hosting site to find interesting
or popular projects. I guess if I did that, a site that made
it easier would loo better to me.

Which goes to show I guess that comparisons have to be
for some purpose and person in order to make sense.

Charlie

[Louis DeJardin]

It kind of feels like it's down to a DVD+R vs DVD-R slash Blu-Ray vs HD DVD situation in most ways. The fundamentals, client gui, and online clearing houses sound like they're close enough already and will likely maintain a functional parity as long as their active.

Seeing how format wars usually pan out my money's on git. All the dotnet open source projects I've built locally in the past year has been on either svn or git. I'm sure Mercurial and BitBucket are great... But from what I can see the technical advantages at this point would need to be clear and monumental to shift the trends...

[Charlie Poole]

Hi Louis,

 

It's different in one way: if you bet wrong on your media format, you'll end up having

to switch in the future as content producers abandon the losing format.

 

In the case of the big online hosting providers it's different. They're not likely to go

away anytime soon and will probably simply offer more choices as time goes on.

Heck, even good old Sourceforge now offers git, bazaar and mercurial in addition

to their longtime cvs and svn support.

 

Whether one of these sites or the other wins the popularity races is only important

to most of us if we are stockholdres. So long as the site you're using is doing for

you what you need done, then there's no reason to switch.

 

Maybe the real question is "Why do we care what's hot?"

 

Charlie

---

From: altnet...@googlegroups.com [mailto:altnet...@googlegroups.com] On Behalf Of Louis DeJardin
Sent: Monday, December 28, 2009 11:50 PM
To: altnet...@googlegroups.com
Subject: Re: What's up with GIT? (was: RE: What's hot / growing in Agile)

[scott...@gmail.com]

Absolutely true, Launchpad looks like a great site for hosting
projects and accepting contributions. I loved the "personal package"
feature.

[Louis DeJardin]

That's still similar to the DVD+R vs DVD-R format war... Manufacturers started making DVD+-R hardware to enable people to pull the trigger w/out fear of being in an obsolete place...

 

But I don't think that really applies in this case. The question's not "which public site will be predominant" rather "which client software" will be most installed and understood. Unless there's a "(h(g)it)+svn" client app that hides the repos format as an implementation detail hosting multiple formats doesn't make the repos selection a moot point.

 

That's the reason I mention there's a number of dotnet projects on git already. For hosting your own projects there's a segment that prefers Hg, and a segment that prefers Git, but because of that trend more people have already installed or will be exposed to Git (often against their will). For open source projects you're more interested in streamlining the experience for people than personal preferences, so it's self-sustaining for addtl migrations off of svn/tfs/etc.

Another anecdotal data point would be: these threads are often "what's up with Git?" not "what's up with Hg?" :)

[Charlie Poole]

Hi Louis,

 

Actually - and in spite of the subject line - my post was in reply to the part of this thread

that has started talking about open source sites like github and launchpad rather than

scm sotware like git and bazaar. I can't see switching sites because one has become

"hotter" than my current site - or even choosing it initially for that reason alone. For

that matter, I wouldn't choose my scm software on that basis either.

 

With regard to client software, your point is well taken, but there is already a

bzr front end to svn clients and both bzr-git and git-bzr projects are well under

way on (respectively) launchpad and github.

 

Charlie

---

From: altnet...@googlegroups.com [mailto:altnet...@googlegroups.com] On Behalf Of Louis DeJardin

Sent: Tuesday, December 29, 2009 2:06 PM

[Glenn Block]

At the higher level whether it is Git, Mercurial or Your Momma's source control :-) is not the most interesting (to me). I think the more important point is the style of development these solutions support vs say SVN, Perforce, CVS, etc. Reading through all the threads it sounds like the specific differences are not major but a matter of preference.

Glenn