fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] fu
I did a quick run through of a changeset submission process with [personal profile] exor674, one for Mercurial and one for Git.


  • pulling from the dev branch back to stable is roughly equivalent between Git and Mercurial, or is easy enough to work around on the committer side, so this is not shown here.

  • we want to move away from asking for patches, to pull requests which include more context

  • we need to concentrate on the branching workflow. We will encourage branching even for small bugfixes or feature development, to make it easy for devs to pick up a different bug once they have submitted a pull request for what they are currently working on.

    This is particularly important because we get devs that happily submit their first patch, and then get frustrated trying to clean up their repo when working on their second. This may also be useful when we discover that tweaks need to be done on review. Instead of doing:

    1. clean up old/current work
    2. grab patch from zilla or a saved file and reapply
    3. do tweaks
    4. generate a new patch containing the original patch + changes requested

    We might do:

    1. save current work on current branch
    2. switch to previous branch
    3. do tweaks
    4. submit pull request again, with the tweaks as a separate commit

    Thus the emphasis on branching in this run through.

  • we're trying to analyze the core features to determine whether they can work the way we need them to, so we've left github and bitbucket out of the equation (except as ways to make the code public)

mercurial workflow using bookmarks )

Git workflow using git branches )

Summary of what we found:

  • When using Mercurial bookmarks, we ran into an odd(?) issue where we lost track of where we were branching from (what would, in git, be the branch "master"). I'm assuming this is a bit of a workflow thing, and we can work around by creating the new bookmark upstream or master, so we could get back to the point in our repo before we started making any changes

  • Same issue, but this time from the committer side? or, since we've merged at this point, and won't need to eep track of bookmarks, perhaps less of an issue?

  • What am I doing when I pull then remove the bookmark? I ... managed to merge, right? That's what I did?

  • Commit messages are now an issue. We standardized around a commit format containing the bug id, commit message, and patch author and enforced it by having the committer supply the commit message.

    Now, we'll either need to enforce a strict policy on commit messages before accepting the commit, or have the committer amend the commit messages beforehand. Other options are to make the changelog hook smarter (detect things of the form "Bug #"?), use a "changelog_bot" for all commits. We might also want to look into having the committer sign off the commit.

    *Finally* this might become a moot point, depending on what's available to us from github/bitbucket that will let us put stuff into the changelog community.

  • need to determine what happens if you try to amend someone's commit in Mercurial by running it through MQ in order to fit guidelines above *points up*. At a guess, we'd end up with a dangling commit that would need to be stripped out of the submitting dev's repo, because the changeset hashes would no longer match

  • git index! oh git index. You might be a pain. The question is, are you a pain that can be hidden away?

  • it's much easier grokking branches, IMO, than bookmarks, because there's never any risk of forgetting where "master" is.

  • git lets me do a merge commit, in order make sure that the bug number is mentioned in a related commit. *Might* be a bit of a moot point if we end up doing a rebase instead of a merge

vlion: cut of the flammarion woodcut, colored (Default)
[personal profile] vlion
per fu and pau's requests, A POST ON BRANCHING. [insert meme with a post on top of a tree branch]

hg branching falls into one of several models:

- clone branching

clone branching is where to make a line of development you execute an `hg clone`, do your development on that copy, and then push/pull back to the mainline. This has the advantage of being the simplest; it also has the disadvantage of being easy to mislay a given clone or to not correctly annotate what that clone does with a rename. It may also be very funky to get this to work right for a DW dev environment if I remember how those work right.

- bookmark branching

bookmark branching is like git branching. git branching is like hg bookmarks. (circular reference. :-) ) You have a name that you have to manually push/pull. Commits usually advance the name of the bookmark as you might expect. These branches can be deleted. So in order to create a branch...

`hg bookmark vlion_sweet_branch`, and then do your development on it, merging as needed from your mainline branch (which should also be bookmarked to be your stable/test branching). Push out to the server with hg push -B vlion_sweet_branch. They do have to be manually pulled, which hg tends to be a bit reluctant to about exposing to the other users. It never says, "Here are teh new bookmarks!"

Bookmarks can be deleted, which is good if you don't want bookmark names cluttering up your namespace.

You only need 1 repo to do development on with bookmarks; switching between bookmarks is as simple as `hg up bookmark_name`.

- named branching

Named branches are what I use at $DAY_JOB. They are permanent. They are very similar to bookmarks, but merging is a little different; the new branches don't actually merge (I can create graphs if wanted). Named branches do get sent up to the server and automatically downloaded.

These are more appropriate in situations where you want to track what happened when and where.
E.g., release is a named branch I frequently use. `Testing` is another.


One approach that seems like a good idea at this time to me is to have a `release` branch, a `test` branch, and a `dev` branch. Patches are developed on bookmarks referencing bug#, splitting off of `dev` until they are done... when the patch is basically done, it's merged into dev. Then when a push seems good, it gets merged by Fu (or other project lead person) into `test` and whatever tests she thinks is good are run... if it's still good, it gets merged to release and is live... if it's bad, then more work on dev is done until it's fixed.

YMMV, and "it seemed like a good idea at the time" doesn't always work out in practice. This sort of approach is fairly enterprise in how it is designed, and might not fully flow with how DW development works.


I'm going to be functionally unavailable until Monday to answer questions (travelling), but I will do my best to answer all questions, even if it's a delayed answer.
deborah: The management regrets that it was unable to find a Gnomic Utterance that was suitably irrelevant. (gnomic)
[personal profile] deborah
I want to spin off a new post from the log of last night's IRC developer meeting. The topic of GitHub came up in the meeting, and some concerns with that idea have been raised in the comments of the previous post. [personal profile] vlion's concerns largely address the difference between mercurial and git, whereas [profile] karelia's concerns also address that difference but touch incidentally on the hypothetical benefit of working in the more public environment of Github.

I was talking to [personal profile] allen and he pointed out that there are really two different issues in play here, because we can go to a shared, public, relatively popular, FLOSS-friendly environment without ever leaving mercurial, namely, Bitbucket.

I'd actually say there are three questions:
  1. Are there benefits to git over mercurial, and if so, are those benefits enough to outweigh the cost of switching to a new source control system?
  2. Would we like to move our source control management to a public, shared, FLOSS-friendly environment? If so, why? Do we think it would be more friendly to our current developers, do we think it would make it easier to bring in new developers, some combination of the two, or something else?
  3. If we want to move to a shared environment, do we feel that there is a strong reason that it should be Github? What are those reasons, if so? If we think git is worse than mercurial, but we do think there's a benefit to moving to Github, which reason should prevail?

Actually, we should probably add a fourth question, which is "would any of our needs be better served by using mercurial more in the fashion for which it was intended?"

Keep in mind when I write these questions that I use github for other projects and like it,and I have never used mercurial intensely enough to have strong feelings about it either way. Personally I fell in love with Perforce at an early date and find all other VCS systems to be it pale yet free imitations. But I do think that if we make a switch like this, these are the questions we need to answer.
kareila: (Default)
[personal profile] kareila
This recent post brought to my attention the fact that it really ought to be simpler for sites using DW code in production to easily keep up with stable milestones of DW development, without having to look through all of our repositories for the most recent milestone tags. Besides, the milestone tags are tied to code pushes on dreamwidth.org and not necessarily an indication of stability!

I propose the following mechanism:

1. Add a "stable" tag to all of our shared repositories. We already do code freezes where we only put in changes to fix bugs that are uncovered immediately after a code push. When the code freeze is lifted, move the "stable" tag to the most recent milestone and leave it there until after the next push/freeze cycle. For example, the most recent cycle would have moved the stable tag from 0.21.2 to 1.0.1 once it became clear there would be no 1.0.2 needed.

2. Add a new site config parameter (something like DW_STABLE) that indicates whether a site is only accepting our "stable" changes.

3. Change the behavior of -update in bin/vcv to only update as far as the "stable" tag if DW_STABLE is set.


Feb. 20th, 2011 12:21 pm
yvi: Rodney Mckay, text: "bad day" (Atlantis - Bad Day)
[personal profile] yvi
I have been trying to actually use Mercurial for my dev work these past few days, and I still don't quite get it.

I have read http://wiki.dwscoalition.org/notes/Dev_Version_Control , so I can now make a new changeset, then do my changes and sync with the live code, but a few things still escape me.

Do I need to use hg qcommit at some point?

How do I unapply all the patches and then sync with the DW repository without Mercurial applying all my patches again?

Do I need to use hg qfinish?

Or, if anyone just wants to sketch out how they work with Mercurial in their dev environment, that would be great.
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
So, a while ago, we closed the 'production' branch in Mercurial. Since then, i've been merrily going along with my 'hack, updating my code regularly, yadda, except for some reason I kept having problems applying patches from the review queue...

...many of you can probably figure out where this is going. So, tonight I was having some trouble with S2 changes in dw-nonfree making my update script error out and die, and Afuna and I realized, finally, that it was because I was still set to the 'production' branch in Mercurial. So, if you're like me and keep having problems applying patches, try this:

hg id

If it says 'production', do this:

hg update -C tip

(When I did that, I got "427 files updated, 0 files merged, 28 files removed, 0 files unresolved". Yowch.)
kareila: (Default)
[personal profile] kareila
I will shortly be pushing changesets that close the staging and production branches in the dw-free repository. The branch system hasn't been used effectively and causes problems whenever cloning a new copy of the repository, so I'm reverting to using the default branch for all development.

There shouldn't be any user facing changes from this, except for one change to bootstrap.pl. However, if you run into any difficulties please let me know immediately. Thanks!

ETA: my testing shows that you may have to manually do hg update -C tip after pulling in the dw-free changes, since the active branch has been switched. After that everything should work normally, although the branches will not appear to be closed until you update Mercurial to a version that supports branch closings.
kareila: Taking refuge from falling debris under a computer desk. (computercrash)
[personal profile] kareila
I've been reading the O'Reilly Mercurial guide, and one item I've run into is the 'hg rename' command for renaming files. We have NOT been using this. Instead, we've been removing the old file and adding the new file.

This is bad for a couple of reasons. One, recent changes to the old file can get dropped on the floor (this has happened at least once). Two, there's a discontinuity in the revision history. You can still access the revision history of the older file under the original file name, but it would be nicer for the entire revision history to remain easily accessible.

Looking Forward

There are a couple of options you can set up in your .hgrc to help with this:

git = true

This will tell hg to use "git-style" diffs, which show that a file has been renamed, not add/removed. There are other differences, such as permission changes, that are ignored by the default diff as well.

addremove = --similarity 100

This tells the "hg addremove" command (which should be executed before every commit, probably - how often do committers forget to add new files to the repo?) to detect when the same file has been removed and readded under a different name, and treat it as a rename instead. Presumably values less than 100 allow fuzzier matching.

Looking Backward

I couldn't figure out a way to correct the revision history in our repository without some hideous branch merging scheme for each changeset containing a failed rename, so for now I'll just make a list of the files that should have been renamed and weren't.

Read more... )

To be clear, I am not placing blame here, but I would like for us all, and most especially my fellow committers, to be aware of the issue and attempt to do the right thing in the future. :)
afuna: Cat under a blanket. Text: "Cats are just little people with Fur and Fangs" (Default)
[personal profile] afuna
I've been thinking a bit about organization, and being able to find out when a particular changeset went live. There are a couple of existing resources which we can look up and use to step backwards, or guess:

Code status, which shows the latest commits with live and non-live; [site community profile] dw_maintenance which announces the code push; [site community profile] dw_dev, with the code tours to get a rough idea of what's changed; [community profile] changelog_digest, which tags entries with "code push", so that it is possible to look up exactly when past code pushes happened.

One more thing I'd like to do is to tag code push commits directly in the repository. That would make it easier to look up when code pushes happened, and which changesets were applied to a particular code push.

That would also make it possible to update to a specific tag, and be able to quickly find when a particular feature/bug was introduced and went out -- whether it had always been that way and no one noticed or whether it was something that just went live in the last code push. We could use the tags to jump between code pushes, or to a commit just before a code push to track down bugs or confirm old behavior.

Each major/announced code push would have its own tag (date of push?). Post major-codepush we tend to have a series of minor codepushes to fix new bugs or tweak existing behavior. These could be grouped together into another tag a couple of days after the major code push (which we could also use to signal that we're finally done with the minor post-codepush pushes, and we can review/commit bigger patches now).

Thoughts, etc?


dw_dev: The word "develop" using the Swirly D logo.  (Default)
Dreamwidth Open Source Development

April 2019



RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Apr. 24th, 2019 07:01 am
Powered by Dreamwidth Studios