> From: Robert Anderson [mailto:rwa000@xxxxxxxxx] > > On Wed, May 21, 2008 at 11:21 AM, Craig L. Ching > <cching@xxxxxxxxxxxxxx> wrote: > > > Hi all, > > I'm a bit of a newbie to Git, but I have started using > it in earnest for > the past couple of months. I had asked on IRC about a > potential problem > I saw with git and how it fit into our workflow. We > currently use CVS > and have used it for the past ten years. A lot of us have grown > accustomed to keeping multiple builds around for > different things, e.g. > defects we're working on, new features, etc., we do a > lot of task > switching and very rarely can we work on something > start to finish > without being interrupted with something else. The > normal workflow of > git seems to cut across that need to keep many builds around. > Generally, building our software is not trivial and > takes a fair amount > of time, so just "git checkout" out a new branch and > rebuilding is not > really an option for us. > > > You haven't explained your issue very well. > > What does "keeping multiple builds around" mean? Taken at > face value this is irrelevant to source control. So you must > mean something else, but you haven't explained what. I keep > multiple builds around by using separate build directories > which are not source controlled. Whether or not I keep > multiple builds of a source tree just isn't relevant to my > source control whether it be CVS or git or whatever. Perhaps > you mean "different variations of the same source tree" or > something like that, in which case "git seems to cut across > that need" seems like an absurd thing to say. > > Can you give an actual scenario, and say how you use CVS in that case? > Sure, what I mean is that you checkout a branch, the workspace reflects the state of that branch. If you do a build in the workspace, the build artifacts match up with the source that's in the workspace. If you then checkout a new branch, it's unlikely that the source reflects the build artifacts any more. Here's how we did it in CVS. Any feature or defect got it's own branch, no matter how trivial it was (yes, it was very painful with CVS, but the benefits outweighed the pain. Moving to Git is very easy for us since we already have the "branch for everything" mindset ;-) ). So, say you have two defects, A and B. We'd create two separate branches named after the defects, so two branches named A and B. Then we'd do: Cd ~/dev/ Mkdir A && cd A && cvs co -r A && make Mkdir B && cd B && cvs co -r B && make That way we'd have two separate workspaces where the build artifacts match with the source. Now, I suppose you could suggest we change our build procedure so that it puts the build artifacts outside of the VCS workspace, i.e. our makefiles could "git branch" and create a directory for those build artifacts outside of the source workspace? That might work, I'd have to think about it a bit more, but I know for our java sources that might be a problem with a lot of java build tool conventions, e.g. maven puts the build artifacts in the same top-level directory that contains the sources. Cheers, Craig -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
