Re: [boost] DCVS vs CVS: call for constructivism
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). I'm working on code.cpp and morecode.cpp. At the same time, I am writing scripts like review.sh (makes git work better with code collaborator) and, say, custom_make.bat. I am going back and forth on these as needed. In particular, as the cpp files get in shape I commit, and maybe post something for review. We leads me to change review.sh. Or as I get things working, I modify custom_build.bat. To me, once done, these are separate commits/branches/features/changelists (whatever you want to call them). But while working on them, I don't want to flip between branches - I find I'm always changing something in the wrong branch when I try separate branches. ie I change code.cpp while in the "scripts" branch. And it is often more than 2 things I am working on. And sometimes (not usually) they are at least somewhat related - ie code.cpp depends on yourstuff.h, and I need to make a small fix in yourstuff.h. In the end, that fix will be separate, but until i know it is correct, it tends to stay mixed with my other work. Now maybe the dependency case is different, I don't know. (obviously at the end of the day, the order of dependent changes needs to be pushed correctly). So basically, in something like perforce, I can group the files into changelists, and then forget about it until something is completely done and ready to commit. I understand I'm losing other features (small commits, being able to easily set it all aside, etc), but this is my common workflow. 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 Sent from my portable Analytical Engine
Gottlob Frege <gottlobfrege@gmail.com> writes:
To me, once done, these are separate commits/branches/features/changelists (whatever you want to call them). But while working on them, I don't want to flip between branches - I find I'm always changing something in the wrong branch when I try separate branches. ie I change code.cpp while in the "scripts" branch.
Done that. :) I'm not sure if this is your intent but the above sounds like you have a branch per file or file-type rather than a branch per topic. Put each feature in a separate branch and don't care about which files a feature might touch. Features are generally easy to identify and develop in a self-contained manner. Sometimes there are dependencies and that's what rebase and merge are for.
So basically, in something like perforce, I can group the files into changelists, and then forget about it until something is completely done and ready to commit. I understand I'm losing other features (small commits, being able to easily set it all aside, etc), but this is my common workflow.
You can always do commits and then rearrange them later via rebase and branch. There's no reason not to do small commits. Heck, you can even chop a larger commit into smaller ones later if you want (rebase + add -i).
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.)
I do the latter whenever possible. Branches are very cheap. I find this workflow helps organize my thoughts. I'm not one who likes to switch from feature-to-feature all the time. But even if I were I'd still want to keep them physically separate as much as possible. In the case where you commit something to the wrong branch, you can do something like this: http://stackoverflow.com/questions/1628563/git-move-recent-commit-to-a-new-b... If you want to put it in an existing branch, checkout the newly created branch, rebase it from the existing branch then checkout the existing branch and merge the new branch in. -Dave
If I understood correctly your context, a dsvc user would have simply cloned locally several times his repo (it s basically copy/pasting), one for each context of work, then work on them separately but maybe at the same time. Then merging the histories (in different or same branch, it s not important) is easily done by making your main work repo pull changes for the other local repos. Your main repo becomes the authoritative repo of your work while the others are more like separate works that need to be merged in the main repo once ready. All this happen only on your disk. It s better to clone repos locally each time you think you ll work on branches or youll experiment or work on an eavy feature. That way you isolate your side work from your normal work and the nature of dsvc allows you to easilly merge both when it s time, if its a good idea (sometime you get far in a feature to discover its wrong, so you just delete the repo and go on). If your question is more: how do I commit only specific files instead of everything that changed; then there are arguments to commit commands to do this. Im most of the time using tortoise hg so its a bit more graphic to choose which file goes in which commit. I do this a lot when I just did a lot of separate semantic changes but didnt think yet about commiting. That said, choosing what to commit is the same in svn. I m not sure I answered your question though. Joel Lamotte
Hi,
So basically, in something like perforce, I can group the files into changelists, and then forget about it until something is completely done and ready to commit. I understand I'm losing other features (small commits, being able to easily set it all aside, etc), but this is my common workflow.
If I understood your description correctly, you might want to look into using stacked git (stgit, http://www.procode.org/stgit/). I've found it convenient for what others have described as the local cycle for patch polish. Your git branch is set up to manage a patch stack, and you go back and forth between patches, transfer patches between branches, make amendments if you find bugs or typos, reorder patches, merge with patches submitted and included upstream, etc. The patch stack change history itself is also versioned, so if desperate you can go back and see what you did to break the code. If your version control use tends to be simple, and your upstream is happy enough to accept rebase-based history for pull requests, or just wants a patch not a git tree to pull from, you might find tools like stgit useful. It's still all git underneath so you can still do all the advanced stuff people have mentioned, if you discover you need to. Regards, Lassi
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.
participants (5)
-
Brian Schrom -
Gottlob Frege -
greened＠obbligato.org -
Klaim - Joël Lamotte -
Lassi Tuura