16

6

When using the "Fork" functionality in Kiln, the new repository appears beneath the one being forked, but is listed as a "Branch Repository", yet when using Mercurial branches in the main repository, it can be tricky viewing a specific branch other than the default branch.

Is it the intent in the design of the Kiln interface to leverage the use of forked repositories, calling them "Branched Repositories" while playing down Mercurial branching?

It is possible to view the main repository at a given revision, id or tag (i.e. "tip"), but I can't seem to find a way to select a given branch. Would it make sense to have a drop-down list of branches to view?

flag
3 
 I too am confused about when and whether to use Mercurial branching vs. cloning new repositories. I searched it a few times on Google and got more "you can do either! hooray!" than advice about which to choose. – Douglas McClean Oct 14 2009 at 21:45

4 Answers

16

There are a few issues you're encountering.

Mercurial has a specific command, called hg branch, that creates something called named branches. Mercurial tools historically did not interact with named branches in a user-friendly manner, and named branches have historically had very confusing and hard to understand behaviors: closing and abandoning branches was problematic, the meaning of the tip changeset and your tags became extremely complicated, and so on. At the same time, I'd be the first to agree that having some type of named branches is very useful.

What Kiln attempts to do is to obviate the need for named branches by making it very easy to have lots and lots of clearly named and well-organized related repositories on the server. We've opted to call those repositories "branch repositories," since their goal is to allow you to have a branch for experimenting on a feature/storing code for later review/etc. (Our terminology of calling them branch repositories, but having the action to make them be called "fork", is a usability bug that I think we need to fix.) All repositories in Kiln, whether branch repositories or central, are full-standing, independent, and (by default) only have the default branch. (You'll see it with a green background right next to tip when you're viewing a repository's history.)

What we encourage you to do is to keep separate branches of development in branch repositories in Kiln, forked off the main repository, rather than using Mercurial's named branches. In addition to the fact that tools support this workflow better, it becomes a lot easier to know what branch you're working with (just see where you cloned from), becomes trivial to discard changes (delete the branch repository), and makes it easy to try experiments without cluttering up the "real" repository's history.

So: we strongly encourage you not to use Mercurial named branches. We instead encourage you to use Kiln's branch repositories to make branch management easy, and to use a clone of a branch repository when you need to contribute to a branch.

If you really do want to use named branches, Kiln fully support them. You can filter to just a single branch head by selecting a branch from the "branches" drop-down menu when viewing a repository's history.

link|flag
1 
 Very informative! I like the idea of using cloned repositories as "branches" (ease of destruction is a big selling point) however, I'm wondering what implication this will have on repositories that have been converted from Subversion. And what is the current best way to view a given tagged revision in Kiln? – Kit Roed Oct 14 2009 at 23:21
How can I diff the tip of two "branch repositories" then? The only way I can think of, is to, in order: 1) hg clone branch A 2) hg pull branch B 3) (Do the diff of the tip of A to the tip of B) 4) hg rollback (if you don't want the changes from B) – Anton I. Sipos May 15 2010 at 1:08
3 
 I think the "branched repository" idea works if you do "shrink wrapped" style projects but not for fast moving projects like a large website where you have to keep rolling out new features/bug fixes daily/weekly. I think this is why some of us are having issues with the "named branches" vs "branches repos". I for one would love to see more support for named branches +1 – Pete Duncanson Aug 6 2010 at 8:56
So, knowing I'm still learning to use Kiln... how am I supposed to merge the branched features back into the main repository? (Without which the branching is pretty useless...) – Carl-Johan Sveningsson Aug 10 2010 at 8:45
Is this still the recommended behavior? – Darian Apr 9 2012 at 14:30
2

I'd like to second Benjamin's note about terminology here: Kiln will soon be getting rid of the "Fork" menu item in favor of simply "Make a branch"

By "making a branch," you can easily create these lightweight branches which is our suggested workflow.

If you want to branch a repo and create a new central repository (one of the gold icons that doesn't live "beneath" any other repository), that'll be an option in the "make a branch" popup.

I'd like to second Benjamin's note about terminology here: Kiln will soon be getting rid of the "Fork" menu item in favor of "Clone to your computer" and "Clone to this server."

By "cloning to this server," you can easily create these lightweight branches which is our suggested workflow.

link|flag
3 
 Your initial answer (what is now struck-though) seemed a little more clear. I'm hesitant to warm up to the idea that a Mercurial cloned repository should be the result of the command "Make a branch". This is clearly a nebulous subject as the distinction between the Mercurial "named branches" and "branch repositories" is likely to be murky at best for many Mercurial/DVCS newbies (including myself!) – Kit Roed Oct 15 2009 at 17:27
Suggestion taken, thanks Kit. We're still discussing. – Ben Kamens♦ Oct 15 2009 at 19:02
1 
 Whatever you decide, consistent use of terms is critical to avoid confusion. If you are describe a "Branched Kiln Repository" as something different from a "Hg Named Branch" then make sure you define the command as "make a Branched Kiln Repository" and always avoid the less descriptive short form - "make a branch". – PJM Oct 26 2010 at 20:33
2

After thinking about this for a while, we've decided to go with the "Make a branch" solution for a few reasons.

1) We'll be getting rid of the "Fork" terminology and instead using "Branch" everywhere. Less terminology is usually good if you're not trying to introduce new behavior into the users' minds.

2) We are trying to describe fewer actions: we simply want people to make a copy of their repository on the server, and almost every source control user that we've come across (including ourselves) intuitively knows this as "branching." The majority of users don't mess with Mercurial's named branches. We'd like to take advantage of this intuition for such a common use case, and...

3) ...we hope to not battle with those that are used to Mercurial's named branches because named branches have all the deficiencies that Benjamin describes. As has been suggested, we're going to implement a client-side extension that warns users when they try to use named branches. Of course, we'll let them go ahead if they want to, but at least we'll give 'em a heads-up so they know that Kiln's alternative is usually preferable.

Note: by "we've decided to go with" I, of course, mean, "we've decided to try out." We'll see how it goes...if this terminology continues to confuse, we'll adjust quickly.

link|flag
4 
 I've been reading up on Mercurial methodologies, (Stack Overflow being an excellent starting point) and have found that it seems that even Mercurial devs themselves use the fork-and-clone approach far more often than named branches. Thank you for all your help and patience in making some sense of all this. – Kit Roed Oct 16 2009 at 15:25
Kit, no problem. Thank you for your continued feedback, it's already proved quite helpful. – Ben Kamens♦ Oct 16 2009 at 16:04
2 
 It would seem to me though that, for large repositories (2GB+) with lots of little files at least, that "making a branch" into a separate repository would make using multiple branches rather painful to clone a branch back to a workstation. How would be the best way to manage such large repositories without loosing the easy branchability that mercurial gives? – cdeszaq Feb 11 2010 at 19:24
Indeed. Picking up a branch in an existing repo involves the transfer of far fewer objects. Plus then your repo has both branches in it - which makes merging and diffing far easier. I'm baffled that fog creek have let a few usability hurdles direct them into a solution which is far less efficient and less useful to the developer. – Martin Long Aug 3 2011 at 9:06
0

For me/us the Kiln Branch Repositories are no option.

Or do i understand this wrong:

Each time you want a "Branch" you need to go to kiln and make a copy of the whole repositorie and clone it to the client?

  • The files we put in the repo are 1.5Gig big.
  • A clone need more than 10mins.
  • Update to another "named branch" takes 10sec.
  • We have absolute path vars in our codebase. So -> rename folder, clone..., edit, commit, rename folder?

Or do i understand anything wrong about Kiln Branch repos?

link|flag
I believe it's possible to clone locally, "branch" in kiln, and push the changes intended for a branch directly from the local clone. – Kit Roed Feb 17 2012 at 14:21

Your Answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.