workflow description for an scm

I setup the bits to make git the scm format for yum-devel. setting it up wasn’t all that difficult, actually. The hard part now is adapting my work flow to work with this.

Here are the set of things I need to do w/an scm:

Thing 1:

check out HEAD from my scm. modify files locally. check in changes and have them be available to all other developers. Dealing with conflicts and merges along the way.

I can do this now with git as it’s been setup. (git pull, git commit -a, git push)

Thing 2:

as we move to a new development cycle in yum I need to be able to take the latest HEAD, make a branch of it to become yum-3.2.X (for example) and diverge from there. So that I can commit new dangerous stuff to HEAD and only put backports and fixes into the yum-3.2.X branch. I do this by making a new sandbox dir for my 3.2.X branch so I can cd into that dir, fire up an editor and work w/o wondering what branch I’m in.

I can _mostly_ do this now in git. the pushing and pulling from branch to branch and getting the changes to the non-HEAD branch is excruciatingly arcane set of commands, but I think it works, sorta.

Thing 3:

From any given branch (HEAD or one of the maintenance branches) I need to create an arbitrary tag which specifies the files in a specific version of yum: re: yum-3-2-3 on the yum-3-2-X branch. or yum-5-0-0 on the yum-HEAD branch. Then with those tags I need to be able to check out a tag like this from my build script, make a tarball and build from there.

I can list the tags, I’m not _really_ sure how to make the tags and if the tags are per-branch or are independent of the branch.

Thing 4:

I want to generate a changelog from commit comments in just this branch, nothing else.

No clue if the log command in git obeys what branch you’re currently on or not. This was one of the things in cvs that always felt odd.

So that is ALL of the features that I require out of an SCM and that is how I do things. Any suggestions on what I should be doing to make the above more obvious to me and to any future contributor?

What I’ve noticed so far is that every time I want to do anything in git I have to be remarkably verbose about what I want. So if I’ve made a new clone and I set the branch to be a local track of some branch remotely, I expect that when I make changes and want to push them that I don’t need to tell it the branch I want to put them in, again. Since it knows where the branch I want to use is when I run ‘git pull’ I would expect it could use that same path for ‘git push’. Tonight I discovered that it can - but only if the local copy of the branch and the remote copy of the branch have the same name. It doesn’t just keep track of it on its own. Even though it is already in the metadata. I’ve played with git enough now to know that I can probably force it to work but it won’t feel all that sane for a while.

Toshio and Warren helped me figure out how to do something similar to that in bzr_ng tonight. The interface to bzr is far and away less painful than git’s. But since a lot of things in fedora sure seem like they’re leaning in the direction of git (most importantly to me fedora-admin scm) I’m trying to learn git as much as possible but as I said today on my email about the yum git repositories:

I don’t work on yum to be good at using git. Nor did I work on yum to be good at using cvs or svn or bzr or hg. They are just means to an end. If I find I’m spending a lot of time screwing around fighting with git (I’m going to exclude this week b/c that’s ALL I’ve done this week) we may see this distributed-scm-experiment come to a shrieking and sudden halt.