Treat top-level branches and child branches equally
Since Plastic SCM does not differentiate internally between top-level branches and child branches, it should also make this clear to the user within the User Interface.
So, instead of having two seperate menu points of "Create child branch ..." and "Create top-level branch ...", merge them together under one clear menu entry "Create new branch ... Ctrl+N"
Then, in the branch creation dialog, let the user decide, what kind of branch he wants to create.
And the default Changeset for the new branch should ever be the changeset, where I'm currently at.
Short summary:
The branches are for me like folders in a file system. They are all the same. It's just up to the user, how he wants to organize them.
But actually, it feels like you are more forced to create child branches, than to have the option to easily create a top level branch instead.
I hope, my intention for this suggestion was clear enough?! :-)
Christian Götz
shared this idea
Discussed with Christian about interesting alternatives but finally we decided (together) not to implement (yet)
-
Göran Wallgren
commented
Hi! We just got started using Plastic after importing 14 years of SVN history... Actually, we imported only trunk + a handful of active branches. The imported branches ended up at top-level. This is ok since most of our branches were major project or release branches, but there were some we would have liked to be child branches logically...
I think we will continue to put our major branches at top-level and create per-subproject and per-task child branches relative to those major branches.
I don't have a problem with the subtle distinction between top-level and child in the GUI. Rather I think it should be used more consequently - in the Branch Explorer the "Create top-level branch..." command is missing. Also, the "Create branch from this changeset/label..." command should be named more appropriately : "Create child branch from this changeset/label..." (the associated dialog says "Create a new child branch from").
-
Hi Christian,
Yes, as you point, you don't really need "on big main", you can have more, you don't even need to use main if you don't want to... but these are all advanced options :-)
What if you write down some of your thoughts and you publish it as guest blogger on our blog?? Contact me at pablo at codice dot es if you're interested :-)
pablo
-
Christian Götz
commented
Thank you very much for the reply!
Of course, branches are no folders. (But you could think about them, as if they were folders. Especially, when you look at the branches in the tree view and the style, how they are labled.)
I'm experimenting with different branching styles, but with the "branch per task" as the base idea.And I came up with the question: "Why should you have only one big [main] branch as top level branch?"
I mean, it's so easy to merge around with plastic scm, that you can merge into any branch you want. (That's also the reason, why plastic scm has no explicit rebase command, right?! You just don't need it to begin a new branching strategy.)
But it is ok, if you do not want to change the GUI for that reason you pointed to. It was just an idea, to bring both branch creation commands together and make them unique. (But with the creation of a child branch as a default, if you want so. ;-))
Kind regards,
Christian -
Hi Christian,
While certainly child branches are just a naming convention (from 4.0 onward, before there was a *huge* difference between them) we feel most users are more comfortable using them than using top level branches. That's why we treat them differently in the GUI.
The comparison between folders and branches sounds too "subversion style" to me :P and you know branches in Plastic have nothing to do with folders ;-)
While I wouldn't be against making top level branches more "first class citizen" for advanced users, I have to admit one of the key things for us is to avoid our users to make mistakes, something we learnt over the years. So... I think it will be confusing for most users to have top level and child branches created at the same place...
We can argue about it... if you convince me, we'll implement it :-)
pablo