Jump to content

Top level branch from top level branch


AaronV_NMR

Recommended Posts

Hello,

I'm evaluating Plastic SCM for the company I work for. I'm trying to create a top level branch from another top level branch. So I want:

main -> develop (top level) -> project (top level)

However, when I create the second top level branch instead I get:

main -> develop (top level)

main -> project (top level)

Is there a means to create the branch hierarchy I desire?

Regards,

Aaron

Link to comment
Share on other sites

Hi Aaron,

A top level branch is just a namespace convention.

You can create "develop" starting from "main", and it will be called "develop" if it is a top-level branch while it would be "main/develop" if it was an ordinary branch. Other than that, their behavior is EXACTLY the same.

Please share more about what you would like to achieve so we can find a better solution.

From here it sounds a little bit like "git flow" πŸ˜‰Β and it is probably too many structure branches to me, but that's just an opinion πŸ˜‰

Β 

pablo

Link to comment
Share on other sites

Hello Pablo,

Good to hear from you and thank you for the quick response.

"You can create "develop" starting from "main", and it will be called "develop" if it is a top-level branch while it would be "main/develop""

Yes, this works exactly as you say. If I could turn this feature off, across all clients, that would be great. I don't want branches to inherit the names of their parent. So I'll likely need to use top level branches for everything. This is because I use a naming scheme for feature branches of "Project\FeatureName". This lets me easily sort branches between projects and shortens the branch names.

As for the issue I encountered, I think I figured it out. However,Β  as some feedback:

If I create a top level branch from another top-level branch that is empty, instead of pointing to the first top level branch, it will point to the first branch in the hierarchy that has a change set. I'd consider this unexpected behavior or at least I didn't expect it to work this way. If I add a change set to an empty branch everything works I would expect when a new branch is created.

Regards,

Aaron

plasticscm_branching.png

plasticscm_unexpected.png

plasticscm_expected.png

Link to comment
Share on other sites

Branches start from a changeset. That’s why an empty branch behaves this way.

Β 

you can play with permissions to deny people creating child branches, or you can create triggers to control the branch hierarchy

Β 

That being said: do you have a Perforce background?

Β 

And, why do you need this complex branch hierarchy? Have you read about our recommended branching pattern?Β https://www.plasticscm.com/book/#_a_perfect_workflow

Link to comment
Share on other sites

Hello Pablo,

It makes sense to have branches rely on change sets. An unfortunate, but reasonable requirement.

" you can play with permissions to deny people creating child branches, or you can create triggers to control the branch hierarchy "

Thank you for pointing out that there are permission options, I didn't realize you could customize the access options like that on branches. I also found a configuration option in the display options where I could uncheck "display full branch names" and I also found the vertical display option for branches. Its nice to see the client and server are flexible. So I'm sure I'll find a combination of display and permission options to get the repo into the state I want.

"That being said: do you have a Perforce background? "ο»Ώ

No. I have a background in Git, SVN, TFS, and CVS (way back in the day).

"And, why do you need this complex branch hierarchy? Have you read about our recommended branching pattern?"

Not in detail, but from a high level it looks like the cactus branching strategy? The company I work for follows a modified version of Git Flow where we create a branch per task/feature (we work to make these changes small per branch and we keep the branches around) and then merge these branches into develop once they've been reviewed. The master branch holds releases. If a release needs to be modified, then we create a branch off the commit from Master to hold just those changes and treat it like its own "develop" branch. Its probably not all that different from what you recommend. However. we do a release every 1 to 2 years. I'd love to release more frequently, but the regulatory environment I work in prevents that.

Regards,

Aaron

Link to comment
Share on other sites

Thanks for the details, Aaron. It is a real pleasure and privilege to learn more about version control from experienced users.

Regarding this:

Quote

It makes sense to have branches rely on change sets. An unfortunate, but reasonable requirement.

What would be your desired behavior?

We changed how branches worked in Plastic eons ago, and I'm always eager to know about other options.

We used to have some sort of branch inheritance where you could make a change to a parent branch and then changes were dynamically propagated to children if they didn't collide, and I used to love it, but it was extremely confusing for mostly everyone.

So, please, share what your ideal behavior would be.

pablo

Link to comment
Share on other sites

Hello Pablo,

Your welcome.

On 8/16/2019 at 4:32 PM, psantosl said:

What would be your desired behavior? ο»Ώ

Hmm... I think git is closer to what I'd want, but I'm not a fan of how minimal branches in git. I don't like that to rename a branch I have to delete it in git. I like that Plastic treats branches more like "objects", but I think its a matter of workflow. For example the reason that I wanted no change sets on my develop branch is that I want the first change set on the develop branch to represent the first feature I add. I really would love no change sets in main either at the beginning.

So my deal work flow for a new project would be:

  1. Create a repo.
  2. Create Main.
  3. Branch Develop off of Main.
  4. Branch a feature branch of a Develop.
  5. Create the initial directory layout and ignore files.
  6. Create a change set for the initial directory layout and files in the feature branch
  7. Merge the first feature branch into develop.
  8. Work on N number of new features.
  9. Merge these into Develop as complete.
  10. Merge develop into Main for the first release.
  11. Continue working in feature branches and develop until another release is ready.

Instead I need to:

  1. Create a repo.
  2. Create the main branch.
  3. Create a commit in main. (Normally a readme.md or .gitignore to have something to check in.)
  4. Create the develop branch.
  5. Make something to create a commit in the develop branch. (Folder structure with descriptive markdown files.)
  6. Work on the feature I wanted to start with.
  7. Merge that feature into develop.
  8. Work on N number of new features.
  9. Merge these into Develop as complete.
  10. Then eventually merge develop into main on release.

Not much different, but its weird that main needs something to create a change set against as a base line. Can't I just have an empty branch as a base change set? Shouldn't the starting point be nothing for the main and no difference for a new branch? Just my 2 cents.

Regards,

Aaron

Link to comment
Share on other sites

Hello Pablo,

But main always have an initial changeset with the root dir.

Indeed! Its a nice feature of Plastic. I guess I was thinking about Git at the time.

also, if you create a branch from another one, they share the same location (like Git) but it is not dynamic or anything. So, not sure why you need the intermediate changeset πŸ˜‰

My apologies if I am confused, but I am not sure what you mean by same location. Do you mean the same change set?

Regards,

Aaron

Link to comment
Share on other sites

Hello Pablo,

Then yes, that is something I don't like about git, plastic, or really any scm I've used. When I branch I'd want the branch to well be branched. I guess this would involve either a branch containing an "empty" change set representing no differences or a commit like command that created a branch at the same time.

Regards,

Aaron

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...