Jump to content

Branch Explorer Confusion after Branch Pull


gregsohl

Recommended Posts

I'm simulating the effort a developer would take in a fully distributed model to pull the main branch to their local repository and begin work on a task. There is an aspect of the Branch Explorer presentation in this sequence of steps I find confusing and want to ask about it. Here are my steps:

1. Create a local repository (Name: default)

2. Create a workspace on new local repository (Name: "doddent matter")

post-1749-0-15570300-1334155781_thumb.gif

3. Set up Sync Replication between local repository (default on GSOHL-DT) and master server repository (default on GSOHL)

4. View pending incoming changes. Pull /main branch from master to local.

post-1749-0-86475400-1334155780_thumb.gif

5. Open Branch Explorer on workspace "doddent matter".

post-1749-0-52561700-1334156063_thumb.gif

When the new local repository is created in step one, I get an empty root changeset. This is expected. After pulling the /main branch from the remote, I end up with a strange layout in the Branch Explorer, since it is ordered by date only, where that original root changeset now appears on the right side of the graph.

It took me a bit to figure out what that empty changeset all the way on the right edge is. Can't tell where its arrow points since it overlaps all the other arrows. I need to basically ignore it, since in a Branch Per Task model I need to create a branch on the last changeset that came from the Master's /main branch. Fine if I choose the branch, not fine if I choose the visibly "most right" changeset, which is really the empty root.

How can I make that empty root less of a visual problem? Can't delete it, its the root.

Thanks.

Greg

Link to comment
Share on other sites

Hello Greg,

How can I make that empty root less of a visual problem? Can't delete it, its the root.

As you said it's only a visual issue, the zero changeset is created by default and it can't be removed. You will forget about it in the next replication.

As the zero changeset of the new repository is newer than the replicated changesets it is shown as the newest one, witch is strange since it seems that the replicated changesets are coming from the past....

Don't be afraid of it, it's only a drawing issue.

Can't tell where its arrow points since it overlaps all the other arrows.

It points to the first changeset replicated.

Fine if I choose the branch, not fine if I choose the visibly "most right" changeset, which is really the empty root.

Yes, in that case you have to be careful, but as I said you before the next replica operation will add changesets after the zero changeset and you will forget about the drawing problem.

Link to comment
Share on other sites

  • 3 weeks later...

I too was expecting to see this in this release. It's strange to see it this way. After changing a branch the branch explorer doesn't visually change at all, yet I feel like it should. One thing that was included in 4.1 is the inclusion of, what I've termed, the "head" icon. It shows up at some points when I have pending changes. If this was always visible it would probably help a lot. Then it becomes consistent. The house icon always shows where you came from, and the head icon always shows where these changes are going to go.

I really think this is all because of a disconnect between what the icon means to the Plastic developers, and what we visually want it to mean as developers. I care so much more about where my changes are going to go than where this branch came from.

Link to comment
Share on other sites

I can't speak for Greg, but I'll do my best to clarify my confusion.

In the Branch Explorer, right-click on a Label and select "Create branch from this label..."

Give it any old name and comment

Select the "Switch workspace to this branch" checkbox.

Hit "OK"

In your branch explorer you now see the new branch. If you look up at your selector information in the GUI at the top left you'll see "Branch /main/TestingBranch" (or whatever name you typed). In your branch explorer though, the house icon is still inside the changeset that you branched from.

The house icon makes me thing "This is where I am right now". As an implementation detail, this is in fact the case because you haven't made any changesets inside the new branch. However, as a developer I'm not concerned with that implementation detail and when I say "This is where I am right now" what I'm really saying is "This is where the changes I make are going to go". The house icon staying on the main branch makes me think when I commit that I'm going to be committing to main.

With the 4.1 release I'm seeing a new icon that represents pending changes. This little icon appears very infrequently, but it's probably the most useful piece in addressing this issue. This icon represents exactly what a developer wants to know: "This is where the changes I make are going to go". I don't know if I'm technically wrong, but I think of it as something very similar to what HEAD represents in Git. I would want this icon to always be shown, similar to how the house icon is currently always shown.

The expected behavior would then be:

In the Branch Explorer, right-click on a Label and select "Create branch from this label..."

Give it any old name and comment

Select the "Switch workspace to this branch" checkbox.

Hit "OK"

Notice "house" icon in the main branch still

Notice the "pending changes" icon in the newly created and now my current branch.

Prior to the new branch being created I would expect a "pending changes" icon to be displayed next to the latest changeset in whatever branch I'm currently in.

Link to comment
Share on other sites

carpediemevive explained it as I would have. Thanks!

The fault is mine for the confusion. I posted this note back on the wrong thread. I had another where I had originally posted related screen shots for the "house" position.

Link to comment
Share on other sites

Thanks carpediemevive!

Yep, I was thinking of the "Pending changes changeset" while writing the post. But as you know the "Pending changes changeset" is only shown when you actually have changes...

Greg, for you which one would be the best approach when you switch to an empty branch?

Link to comment
Share on other sites

I believe the house should be in sync with your workspace. So when switching to an empty branch, the house should move to that empty branch. The line / arrow drawn from that empty branch to its source changeset is all that is needed to know ancestry.

Greg

Link to comment
Share on other sites

What carpediemevive and I are saying is that we don't look at the house based on your internal implementation details that tie it to a changeset. Visually, to us, it should represent what branch and my workspace is on and if there are changesets in the branch, what changeset the workspace is on.

It sounds like your implementation makes that hard. But perhaps it is the implementation that is incorrect. You know where my workspace is pointed. The selector names it. CM WI shows it. We just want the house to show it too. Otherwise it appears that a commit/checkin will be going to the wrong place.

Link to comment
Share on other sites

  • 4 weeks later...

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...