2

I'm very new to this version control business and slowly learning my way. I've learned how to create a repository and to commit changes to it. The story right now (for which I think version control is perfect, though I'm not sure the best practice) is this:

I have software A. It is generic.

I need to modify 2 files in the codebase for Company B. This will make it Software B.

That's the ONLY change I need to do; after that I just want to continue working on A as if Software B had never existed.

What is the best way for doing this? Just exporting Software A, modifiyng it and sending it to the client? Working within the repository, committing, and then "backing out"? I've tried fudging with the close branch and branch but either I'm too dumb to get it to work or its broken (I keep getting "HEAD ALREADY CLOSED" or something).

Any pointers to tutorials about this would be helpful - and I really stress, as annoying as it may be, I'd like help on how to do this from within the tortoise GUI on Win7, NOT the command line please.

dama_do_bling
  • 244
  • 5
  • 17
  • 1
    I'm kind of confused... Your title speaks of Mercurial but the question is about SVN, which one is it ? – krtek Dec 16 '11 at 21:30
  • sorry, fixed. i was using SVN as a synonym for version control system. ouch. – dama_do_bling Dec 16 '11 at 21:34
  • using command line, you'll be much more protuctive. hg branch SoftwareB hg commit -m "Changes to client B" hg up default – Zote Dec 16 '11 at 23:55
  • You **must** to read Steve Losh articles about different branching strategies - named branches is just one (mostly mentioned) method from 3 total – Lazy Badger Dec 17 '11 at 00:32

2 Answers2

6

OK. You can and have really use Mercurial branches, at least one additional branch per client

  • Don't close customers branches
  • Use distinctive names

I need to modify 2 files in the codebase for Company B. This will make it Software B.

  • Edit files, save changes.

Shot 1 - before branching

  • Start commit procedure, i.e in commit pane click on "Branch: default" text (which works like button really) and in this form select 2-nd choice "Open new named branch", select name of branch, press OK. This effectively change branch for this (still unfinished) commit

NewBranch in progress

  • Enter commit message, press Commit button (see Right-Top on Shot2), confirm creating new branch
  • After commit workbench window will show you one more commit, and revision 1 (in my example) is from different branch Cust1 ("Branch" column content and green label in changeset "Description"), revision 0 still in default and we are in active revision 1

We branched code

  • When return to mainline is needed - RClick on needed (latest in default branch?) changeset in changeset-list and "Update" from conext-menu - we change the point, in which our WC mirror repo, to some previous state (checked by file-content verification)

Updated to older CSet

  • Fix base code, commit without touching options

Two active branches

  • If we have change customer's version - update to latest cset in his branch

Update to branch

edit and commit

Commit to branch

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
0

I think the best is to create a named branch for your changes. It will be more flexible if you need to do some later changes for the B client. The following steps should be fine to do this :

  1. Create a new branch on your repository. This SO question should help if needed : How to branch with TortoiseHG
  2. Do the changes you need to do
  3. Commit them in the new named branch
  4. Switch back to the default branch
  5. Forget about the branch you created before (You can also close it if needed)

The following links can help you :

  1. http://blog.caraulean.com/2011/03/09/working-with-named-branches-using-tortoisehg-2-0-illustrated-workflow/
  2. TortoiseHg and multiple branches in one repo
Community
  • 1
  • 1
krtek
  • 26,334
  • 5
  • 56
  • 84
  • By "switching back" you mean just make the general changes, then change the branch again to default and click "commit"? there's no reason to "close branch", right? – dama_do_bling Dec 16 '11 at 21:55
  • You must change the branch to default **after** committing the changes. Have a look a the first link provided, it shows everything with screenshots. And there's no real reason to close the branch, it's only an "aesthetic" thing – krtek Dec 16 '11 at 22:33