Skip to main content

Home/ dvcs-vs-vcs/ Group items tagged workflow

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Daniel Jomphe

The Thing About Git - 0 views

tomayko.com/...the-thing-about-git

comparison git learning versioncontrol versioning dvcs-vs-vcs

shared by Daniel Jomphe on 29 Sep 08 - Cached
  • Version control systems have traditionally required a lot of up-front planning followed by constant interaction to get changes to the right place at the right time and in the right order. And woe unto thee if a rule is broken somewhere along the way, or you change your mind about something, or you just want to fix this one thing real quick before having to commit all the other crap in your working copy.
  • You can work on five separate logical changes in your working copy – without interacting with the VCS at all – and then build up a series of commits in one fell swoop. Or, you can take the opposite extreme and commit really frequently and mindlessly, returning later to rearrange commits, annotate log messages, squash commits together, tease them apart, or rip stuff out completely. It’s up to you, really. Git doesn’t have an opinion on the matter.
  • I’ve personally settled into a development style where coding and interacting with version control are distinctly separate activities. I no longer find myself constantly weaving in and out due to the finicky workflow rules demanded by the VCS. When I’m coding, I’m coding. Period. Version control - out of my head. When I feel the need to organize code into logical pieces and write about it, I switch into version control mode and go at it. I’m not saying this is the Right Way to use Git: in the end, it all goes to the same place. I’m saying that this is the way I seem naturally inclined to develop software, and Git is the first VCS I’ve used that accommodates the style.
  • ...20 more annotations...
  • Taking Control of Your Local Workflow
  • Git means never having to say, “you should have”
  • The big problem here is models.rb - it’s “tangled” in the sense that it includes modifications from two different logical changes. I need to tease these changes apart into two separate commits, somehow. This is the type of situation that occurs fairly regularly (to me, at least) and that very few VCS’s are capable of helping out with. We’ll call it, “The Tangled Working Copy Problem.”
  • Git is quite different in this regard. You can work on five separate logical changes in your working copy — without interacting with the VCS at all — and then build up a series of commits in one fell swoop. Or, you can take the opposite extreme and commit really frequently and mindlessly, returning later to rearrange commits, annotate log messages, squash commits together, tease them apart, or rip stuff out completely. It’s up to you, really. Git doesn’t have an opinion on the matter.
  • I've personally settled into a development style where coding and interacting with version control are distinctly separate activities. I no longer find myself constantly weaving in and out due to the finicky workflow rules demanded by the VCS. When I'm coding, I'm coding. Period. Version control – out of my head. When I feel the need to organize code into logical pieces and write about it, I switch into version control mode and go at it. I'm not saying this is the Right Way to use Git: in the end, it all goes to the same place. I'm saying that this is the way I seem naturally inclined to develop software, and Git is the first VCS I've used that accommodates the style.
  • The Index is also sometimes referred to as The Staging Area, which makes for a much better conceptual label in this case. I tend to think of it as the next patch: you build it up interactively with changes from your working copy and can later review and revise it. When you're happy with what you have lined up in the staging area, which basically amounts to a diff, you commit it. And because your commits are no longer bound directly to what’s in your working copy, you're free to stage individual pieces on a file-by-file, hunk-by-hunk basis. Once you've wrapped your head around it, this seemingly simple and poorly named layer of goo between your working copy and the next commit can have some really magnificent implications on the way you develop software.
  • We want to commit all of the changes to synchronize-bookmarks and some of the changes to models.rb, so let’s add them to the staging area:
  • add bin/synchronize-bookmarks
  • add --patch models.rb
  • tage this hunk [y/n/a/d/j/J/?]?
  • Stage this hunk [y/n/a/d/j/J/?]?
  • I run into The Tangled Working Copy Problem so often that I've devised a manual process for dealing with it under VCS’s that punt on the problem. For instance, if I were using Subversion, I might go at it like this:
  • The magic is in the --patch argument to git-add(1). This instructs Git to display all changes to the files specified on a hunk-by-hunk basis and lets you choose one of the following options for each hunk: y – stage this hunk _n_ – do not stage this hunk _a_ – stage this and all the remaining hunks in the file _d_ – do not stage this hunk nor any of the remaining hunks in the file _j_ – leave this hunk undecided, see next undecided hunk _J_ – leave this hunk undecided, see next hunk _k_ – leave this hunk undecided, see previous undecided hunk _K_ – leave this hunk undecided, see previous hunk _s_ – split the current hunk into smaller hunks
  • I like to review that the changes in the staging area match my expectations before committing: $ git diff --cached [diff of changes in staging area]
  • I also like to verify that my unstaged / working copy changes are as I expect: $ git diff [diff of changes in working copy that are not in the staging area]
  • Everything looks good, so I commit the staged changes: $ git commit -m "fix bookmark sucking problems"
  • git add --patch is actually a shortcut to features in git add --interactive, a powerful front-end for managing all aspects of the staging area. The git-add(1) manual page is a treasure trove of worthwhile information that’s often passed over due to the traditional semantics of VCS “add” commands. Remember that git-add(1) does a lot more than just add stuff – it’s your interface for modifying the staging area.
  • git commit --amend takes the changes staged in the index and squashes them into the previous commit. This lets you fix a problem with the last commit, which is almost always where you see the technique prescribed, but it also opens up the option of a commit-heavy workflow where you continuously revise and annotate whatever it is you're working on. See the git-commit(1) manual page for more on this.
  • And then there’s git rebase --interactive, which is a bit like git commit --amend hopped up on acid and holding a chainsaw – completely insane and quite dangerous but capable of exposing entirely new states of mind. Here you can edit, squash, reorder, tease apart, and annotate existing commits in a way that’s easier and more intuitive than it ought to be. The “INTERACTIVE MODE” section of the git-rebase(1) manual page is instructive but Pierre Habouzit’s demonstration is what flipped the light on for me.
  • There’s a section of the Git User’s Manual called The Workflow that describes, at a fairly low level, the various interactions between the working copy, the index, and the object database.
Daniel Jomphe

'Re: clarification on git, central repositories and commit access lists' - MARC - 0 views

lists.kde.org/?l=kde-core-devel&m=118776516931648&w=2

comparison dvcs git vcs dvcs-vs-vcs

shared by Daniel Jomphe on 29 Sep 08 - Cached
  • With that I mean that in KWord I tend to work on a feature by first writing a unit test and committing that. After that I start to implement the feature until it actually passes the unit test and after that I add UIs etc etc etc. In other words; it takes me a week with 30 commits before I finish this new feature. And finish naturally doesn't mean bug-free. During this time I will surely find bugs in other pieces of code, or simple little features to add there. I commit those separately. All the above goes into one git tree and depending on how much I work with others on the features I publish that git tree. But the small fixes will be committed to the 'release' tree (aka svn) as soon as possible. At the end of the week when my feature is 'done' I will also push that upto the release tree. So, what IMOHO you, as a svn user, will end up with is the trunk that doesn't have half finished features that mess everything up. You will still see the current development (mostly) but not the dirty work-in-progress-excuse-the-mess versions. As an example; in Krita we have this excellent GSoC project for color mixing, the author programs in trunk and thus commits everything there. We have had a couple of times when his commits made it hard for others to try out his work. I.e. it was quite broken. I'm all for experimentation so I'm not complaining. But at the same time I do see it as a great opportunity for Git where I can imagine him committing his work-in-progress that is known to create regressions and publish that for other interrested people to see. And only after a week of hacking commit his updated version to the release tree so everyone can enjoy it. leaving the release tree free from major regressions.
  • And I believe that Git actually helps by allowing others to see a more representative version of the software instead of one that is constantly in flux.
  • All the workflows you are used to are still there, there just are more workflow possibilities and thus more ways to get productive. So, I really don't think it is in any way an extra barrier. It actually tears down several barriers.
Daniel Jomphe

SVN 1.5 - 0 views

dot.kde.org/1219991729

comparison dvcs git vcs dvcs-vs-vcs

shared by Daniel Jomphe on 29 Sep 08 - Cached
  • that's not the whole picture. First and foremost you forgot the disconnected part. You can't commit to Subversion unless you can reach the repository, which is often in a server over the Internet. Also, each developer isn't restricted to one branch. He very often has a lot of them. Right now I have 28 separate branches of Qt in my workstation: they range from previous stable releases of Qt (to test regressions and fixes with) to branches I created to start working on fixing tasks to research projects.
  • And that's just my private branches. When I am collaborating with other people in projects, I have more branches. For one project right now in Qt, we are tracking 4 or 5 different branches, each with a different "theme": optimisations, new features, animations, etc. And there's an extra branch which is the merger of all those "theme branches", so that we can get a feel of what it will be when it's done.
  • Finally, you're also forgetting the ability to undo, redo, and modify your work. Once you commit to Subversion, it's there for life. Removing something from the repository means dumping and reloading it. With a Git, you can undo your commits, change them, squash them together without problems. (You can do that after you've published them, technically, but you shouldn't)
  • ...1 more annotation...
  • people are asked to only commit stuff to trunk when they are done with it. Which for refactors and bigger things means it may be a week or more before you can commit it. And due to that requirement, thiago's post becomes very relevant. Those tools are essential to a scalable workflow.
Daniel Jomphe

Akademy Redux: Release Team Members Propose New Development Process - 0 views

dot.kde.org/1219926799

comparison dvcs git vcs dvcs-vs-vcs

shared by Daniel Jomphe on 29 Sep 08 - Cached
  • The centralized development system in Subversion's trunk doesn't support team-based development very well
  • Furthermore we're still looking for more contributors, so lowering the barrier for entry is another important concern.
  • We will have to allow for more diversity and we must be able to accommodate individual workflows.
  • ...15 more annotations...
  • Companies have their schedules and obligations, and what is stable for one user or developer is unsuitable for another.
  • Together with new tools for collaborating, new development models are emerging.
  • And we have an increased need for flexible and efficient collaboration with third parties and other Free Software projects.
  • KDE's development process should be agile, distributed, and trunk freezes should be avoided when possible.
  • We should set up a process aimed at adaptation and flexibility, a process optimized for unplanned change.
  • Currently, our release cycle is limiting, up to the point of almost strangling our development cycle.
  • Our current release process, depicted in the graphic below, can be described as using technical limitations to fix what is essentially a social issue: getting people into "release mode".
  • many developers complain about Subversion making it hard to maintain "work branches" (branches of the code that are used to develop and stabilize new features or larger changes in the code), subsequent code merges are time-consuming and an error-prone process.
  • The proposal would essentially remove these limitations, instead relying on discipline in the community to get everyone on the same page and focus on stability. To facilitate this change, we need to get the users to help us: a testing team establishing a feedback cycle to the developers about the quality and bugs. Using a more distributed development model would allow for more flexibility in working in branches, until they are stabilized enough to be merged back to trunk. Trunk, therefore, has to become more stable and predicable, to allow for branching at essentially any point in time. A set of rules and common understanding of the new role of trunk is needed. Also, as the switch to a distributed version control system (which is pretty much mandatory in this development model) is not as trivial as our previous change in revision control systems, from CVS to Subversion. Good documentation, best practice guides, and the right infrastructure is needed.
  • KDE's current system of alpha, beta and release candidate releases will be replaced by a system which has three milestones:
  • The Publish Milestone This is the moment we ask all developers to publish the branches they want to get merged in trunk before the release. Of course, it is important to have a good overview of the different branches at all times to prevent people from duplicating work and allow testers to help stabilize things. But the "Publish Milestone" is the moment to have a final look at what will be merged, solve issues, give feedback and finally decide what will go in and what not.
  • The Branch Milestone This is the moment we branch from trunk, creating a tree which will be stabilized over the next couple of months until it is ready for release.
  • The "tested" milestone represents the cut-off date. Features that do not meet the criteria at this point will be excluded from the release. The resulting codebase will be released as KDE 4.x.0 and subsequently updated with 4.x.1, 4.x.2, etc. It might be a good idea to appoint someone who will be the maintainer for this release, ensuring timely regular bugfix releases and coordinating backports of fixes that go into trunk.
  • Under discussion are ideas like having some kind of "KDE-next" tree containing the branches which will be merged with trunk soon; or maybe have such trees for each sub-project in KDE. Another question is which criteria branches have to meet to get merged into the "new" trunk.
  • Having a page on TechBase advertising the different branches (including a short explanation of their purpose and information about who's responsible for the work) will go a long way in ensuring discoverability of the now-distributed source trees.
1 - 6 of 6
Showing 20▼ items per page