Jump to content

JakubH

Members
  • Posts

    205
  • Joined

  • Last visited

  • Days Won

    13

JakubH last won the day on September 17 2014

JakubH had the most liked content!

Recent Profile Visitors

5,127 profile views

JakubH's Achievements

Newbie

Newbie (1/14)

  • Conversation Starter Rare
  • Week One Done Rare
  • One Month Later Rare
  • One Year In Rare

Recent Badges

23

Reputation

  1. Checkin comments has a usefull feature – a popup with recent comments. I often select one of recent comments and just changed that, as our checkin comments conventions says it should start with certain prefix, so it is often more convinient to select a similar recent comment and edit it. I updated to 11.0.16.6949 (classic PlasticSCM GUI on Windows) to see that it incorrectly fills in this popup menu. Comments containing underscore "_" are broken to two comments. For example: Comment "MERGE from rel_8.8" would be shown as "MERGE from rel" and "8.8".
  2. My first impression is good. I use manually "pinned" tabs too. Mine are Workspace Explorer, Pending Changes, Branch Explorer (and sometimes Sync repositories), in this order; but I can get used to the order from the blog post, so this should be OK for me.
  3. Um. That's a trap. There is a cherry pick operation, which allows to bring a specific changes to another branch, but it puts the branch in this kind of inconsistent state without an easy way out. I wish there was an optional 2 way merge at least. Moreover, the GUI describing the conflict is really confusing. It doesn't show the two revisions of the file, so it seems that they are the same and therefore no merge is needed. The true is that the merge is needed but Plastic is not able to do that. That user voice request is actually one of the most wanted – top #3, by now. So, I guess I am not the only one encountering this.
  4. We have one serious issue here. I just find out that if somebody add a new file in one branch, cherry pick that changeset to a child branch and after some time he/she wants to merge from the second branch to the first one, the file cannot be merged! I knew already about an evil twin conflict and the inability of Plastic to solve this type of conflict by a merge. I thought that a workaround to this is to make sure to check-in a file in one branch only and cherry pick it to other branches if needed. Now, I see it is not always a solution. In the described case the problem is even hidden, because Plastic offers an option to View content of the item loaded twice only (which looks like there is only one version of the file, so no merge is actually needed) but this is possibly not the sole version of that file. There might be a different revision in the other branch. What user typically wants is to merge those two revisions, but he/she can't! I don't understand why. May you bring some light into this area? (My primary system is still Plastic 4.1, I haven't tried this in Plastic 5 yet.)
×
×
  • Create New...