Re: [boost] DCVS vs CVS: call for constructivism

Subject: Re: [boost] DCVS vs CVS: call for constructivism
From: Brian Schrom (brian.schrom_at_[hidden])
Date: 2012-03-23 11:45:06

On 03/22/2012 08:50 PM, Gottlob Frege wrote:
>   I have a question for the git (or hg) people. Maybe the concrete
> situation will shed some light on some of the issues (or maybe I'll just
> get some help and stop pulling what's left of my hair out).
>
> Should I do everything on a messy "work" branch and just sort it out when I
> am ready to push? Should I keep the features in separate branches, but pull
> from branch to branch all the time? (I don't think I want to spend that
> much time with the RCS. I like forgetting about it most of the time.)
>
> Am I just doing it wrong? (And did any of this make any sense?)
>
> Tony
>
>

My opinion is you should work the way you want to work and the tool
should enhance your work flow and may ultimately end up changing the way
you work.

Some experiences that initially sold me on using git (and likely other
dvcs's but I haven't tried them) were:

0) git-svn It worked well enough with tutorials and such that I could
whet my appetite.  I did rm -rf my cloned tree quite a few times the
first week...

1) the stash command.  I'm working on my main tree (no branches yet
because I always used separate working copies for my alternate methods
in svn).  Someone needs a quick fix.  I stash all of my current changes
onto a "patch stack" now my tree looks clean like I've just checked
out.  I fix the couple lines, commit, push (dcommit with git-svn), and
pop the stash which merges my previous work with the quick fix in my
working copy and I'm back to where I was before I was "interrupted." 
This setup is able to happen before I've completely lost my train of
thought of the feature I was working on.  Stash is also key for working
with git-svn for being able to sync with the svn repo and having changes
in the WC...After switching to pure git repos, I don't use stash nearly
as much, but it was a great first impression.

2)  git gui tool.  It is simple enough to rapidly see what has changed,
write your commit message, and commit.  It's a very lightweight gui. 
Then I stumbled across cherry picking, you highlight the lines you want
in or out of the commit, and you've now made a new patch.  I know svn
added this a while back, but I've never used it.  Not sure why, probably
because it wasn't there when I first started using svn and developed my
svn habits...

3)  Branches.  Eventually I got brave and explored branches...The end
result is I only have one tree for a project and a branch for every
feature/variant I'm working on.  I used to have a separate working copy
directory for each svn.   In the beginning, I was confused often by what
branch am I in now?  However, gitk is a great tool to graphically show
the history of branches.  git gui has great support for working with
branches, and now I'm just in the habit of running 'git branch' much as
I type 'ls' a lot.  I think there are some shells that allow you to
include the branch name in the command line prompt, but I haven't needed
that yet.  Again, svn has had 'svn switch' for a while but for some
reason, it never became part of my routine working style.

4) The concept of "staging."  It caused no end of confusion initially. 
In svn, the WC is the stage.  In git (presumably other DVCS), the stage
is decoupled from the WC.  It's quite valuable to use git gui to see
what is staged for committing.  I'm not exactly sure why, but it's
comforting to really know what's going in your commit before happens.  I
think the main difference from a user perspective is that git allows me
to be more sloppy during development, i.e. modify many files not
necessarily related to a feature that I want to check in, but be very
precise when I do check in (and to fix my mistakes with amend last
commit) if I catch them quickly enough, i.e. forgetting to 'add' a file.

5) As shared in the other thread, each generation of vcs has had a
profound impact on my development style.  Starting with making backup
directories, to scripts that make backup tar balls, to rcs, to cvs, to
svn, and now to git.  The number of "commits" I make have increased in
frequency with each tool.  I guess this gives me more courage to
refactor more aggressively or explore different ideas more readily
because I know I can roll back to a previous working state and that I
haven't spent much time investing in the attempt and I can delete it,
clean it up, and make it pretty before I have to share the patch with my
peers.

6) Not very objective, but my experience with git vs svn is that git is
lightweight (fast) enough to be part of my development while I develop
vs svn which seems more heavyweight and part of the process that I do at
the end of development rather than something I use during.