Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

Rename support on merge

Friday, August 27, 2010 Pablo Santos 0 Comments

I'm going to go back to the basics today and describe how Plastic handles renames during merge with two different cases:
  • Rename a file, modify it in parallel in a second branch and check how the two branches are correctly merged back, which means: the result file is renamed and it contains the changes from the two branches.
  • Divergent merging: what if we rename a file in one branch and also in a second one to a different name and we merge back?

    As simple as it might sound, renaming during merging is one of the points where most of the SCMs break... And the good news is that Plastic simply excels there.

    Handling renames during merge


    The scenario is very simple:
  • Create branch task003, rename and modify file agent.cs there
  • Create branch task004 (in parallel with task003) and modify agent.cs there
  • Merge back both branches to main
    The expected result is: getting agent.cs renamed and including the changes from the two branches.

    This is what Plastic does, but systems like Subversion dramatically fail: SVN will create two files as result and won't directly merge the changes...

    The following screencast shows Plastic in action dealing with this example:



    Divergent renaming


    The scenario is the following:
  • Rename a file on a branch
  • Rename the file to a different name, in parallel, on a different branch
  • Merge the branches together

    Plastic is able to detect the double rename and come up with a solution: choose one of the names or propose a new one. But Plastic won't end up creating two files and leaving you alone to handle further merging (changes on the files) yourself.

    Interestingly this is exactly what Mercurial does: it will create two files with the two names and warn you to solve the situation somehow.



    Check it in action here:

    Pablo Santos
    I'm the CTO and Founder at Códice.
    I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
    I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
    I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
    And I love simple code. You can reach me at @psluaces.
  • 0 comentarios:

    Who we are

    We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

    If you want to give it a try, download it from here.

    We also code SemanticMerge, and the gmaster Git client.

    Shell Extension tour

    Thursday, August 26, 2010 Pablo Santos 0 Comments

    One of the key features in the new Plastic SCM 3.0 is the Windows Shell Extension integration.

    It's a feature that users coming from SVN or CVS were missing (the great "tortoise" family of tools, you know) so we finally cached up here, did our homework and released a very neat integration.



    The really cool thing about the ShellExt is that you can use the entire Plastic GUI from it: the branch explorer, running merges and diff, the changeset browser, code reviews... everything is just there... which ends up creating a very tightly integrated and neat interface. You can access all the replication functionalities too, of course.

    Here's a short screencast (remember we've a YouTube channel) here showing most of the views popping up and so on.


    The ShellExt shares most of the code with the Windows GUI, which is great for maintenance. We had to do a good refactor of some pieces (not that big at the end :P) in order to be able to display "views" on standalone windows, and then also some threading considerations to integrate with Explorer, but the result, IMHO, is really good.

    Enjoy!
    Pablo Santos
    I'm the CTO and Founder at Códice.
    I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
    I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
    I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
    And I love simple code. You can reach me at @psluaces.

    0 comentarios:

    Who we are

    We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

    If you want to give it a try, download it from here.

    We also code SemanticMerge, and the gmaster Git client.

    Plastic SCM GUI text misalignment on Ubuntu

    Wednesday, August 18, 2010 Miller Auker 0 Comments

    Have you experienced that Plastic SCM GUI on Ubutnu 9.04-10.04 have
    some windows with text that is misaligned, Well, it is a known Ubuntu bug that is related to the fonts mapping from
    Microsoft Sans Serif to Thai font which is affecting the scaling
    of the fonts. Illustrated in the figure below.



    To resolve the issue, you will need to edit the font configuration file
    /etc/fonts/conf.avail/89-ttf-thai-tlwg-synthetic.conf


    Change the <string>Loma</string> to <string>DejaVu Sans</string> as indicated in figure below.



    No need to restart the Ubuntu, the fix is instant, and the results are illustrated in the figure below.




    The issue is discussed in the following link and a fix for future Ubuntu releases seems to be encouraged.
    https://bugs.launchpad.net/ubuntu/+source/thaifonts-scalable/+bug/539008

    0 comentarios:

    Who we are

    We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

    If you want to give it a try, download it from here.

    We also code SemanticMerge, and the gmaster Git client.

    Agile Retrospectives (II): Phases

    Tuesday, August 10, 2010 Luix 4 Comments

    In the last article I talked about general concepts related to retrospective meetings and several issues to take into account when planning a meeting.
    This time I'll describe the different phases of a retrospective in detail. As all of you already know, these phases are:
    1. Set the stage.
    2. Gather data.
    3. Generate insights.
    4. Decide what to do.
    5. Close the retrospective.
    Set the stage

    Introduce the meeting; try to make that everyone gives his/her opinion, how he or she feels about the last sprint (or iteration in general terms, remember that I'll focus mainly on SCRUM). Be brief, but the most important thing here is to make that every member of the team says something. The best way to achieve this is asking how everyone feels about the last sprint, and what they want for the next one.

    Establish the duration of the meeting and the different points to discuss. In addition to this, describe a list of objectives or rules that identify the team and that must be accomplished during the meeting. Example: "Every one must participate".

    Gather data

    Not only gather data, but also share it with the team. This information improves the perspective that every member has about the context, making that the team talk about their general impressions instead of their personal insights. It is essential that every member shares his/her
    feelings about the last sprint. Don't ask directly about feelings, but indirectly, such as: when did you come to work happier? which task did you enjoy more? when did you come to work simply because you had to? which task did you find boring/less interesting?

    Generate insights

    This is the appropriate moment to think about 'why?' and to decide what should be done in a different way. Make that the team think about conditions, interactions and patterns that may lead to success. Identify and study problems, risks and bad results.

    Decide what to do

    Select two improvement points (no more) for the next sprint, and plan to do them. Too many points of improvement tends to overload the team, it creates stress and in the end it is probable that none of them are achieved.

    Plan a break between the retrospective and the plan meeting, so that the people think about what and how to plan taking into account the decisions made in the retrospective meeting.

    Close the retrospective

    Close the meeting properly and decisively. Summarize the conclusions. Write all the issues covered during the meeting in a blackboard, so that everyone can see them. Include the improvement points to do and the decisions made. It is very important to remark that those decisions adopted are property of the team, not of the manager. Thus we'll avoid that when everyone leaves the meeting room they forget everything until the next meeting.

    Upcoming...

    Activities to do during the retrospective meeting, which aim is to make that every person participates in the meeting, promoting insights, fresh ideas and points of improvement. See you, then.



    Bibliography:

    Agile Retrospectives: making good teams great

    Esther Derby & Diana Larsen

    Agile Retrospectives: how to improve the meetings and the results
    (Part I of the series)

    4 comentarios:

    Who we are

    We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

    If you want to give it a try, download it from here.

    We also code SemanticMerge, and the gmaster Git client.

    Branch per task workflow explained

    Thursday, August 05, 2010 Pablo Santos , 17 Comments

    My goal is to explain how the branch per task pattern (a.k.a. issue branches, task branches, feature branches and even bug branches) works and why is so good to keep projects under control.

    Branching and merging is a key topic nowadays, specially due to the raise of DVCS, so I expect you find this post on branch and merge strategies worth. :)

    I'll try to cover also the relationship between this pattern and agile methodologies like Scrum.

    I'll also highlight why branch per task is the core of parallel development and why it is much better than serialized development or trunk development.

    Pablo Santos
    I'm the CTO and Founder at Códice.
    I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
    I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
    I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
    And I love simple code. You can reach me at @psluaces.

    17 comentarios:

    Who we are

    We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

    If you want to give it a try, download it from here.

    We also code SemanticMerge, and the gmaster Git client.

    Plastic SCM 3.0 running on Mac OS X

    Wednesday, August 04, 2010 Pablo Santos 2 Comments

    As promised, a few more screencasts showing Plastic 3.0 running on Mac OS X. Remember to view them in full screen and HD :)



    And another one:

    Pablo Santos
    I'm the CTO and Founder at Códice.
    I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
    I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
    I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
    And I love simple code. You can reach me at @psluaces.

    2 comentarios:

    Who we are

    We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

    If you want to give it a try, download it from here.

    We also code SemanticMerge, and the gmaster Git client.

    View switcher and Mac OS X screencasts

    Tuesday, August 03, 2010 Pablo Santos 4 Comments

    We've introduced a feature in 3.0 that users were demanding: a better way to switch between active views on the GUI using the keyboard.

    We came up with the "view switcher": you press CTRL-TAB and you switch from one view to the next, as you'd do between windows on Vista.

    I've recorded a short screencast but this time on MacOS X instead of using Windows, just to demonstrate how 3.0 looks like on the Mac.

    For the folks on the Mono Project, it's worth noting what the great Mono WinForms (MWF) can do with a little bit of design! :)




    Beautiful, uh? :)

    I'll be posting more screencasts on the coming days, specially showing the branch explorer on Mac OS X and the 3D version tree, which are probably the coolest ones...

    But first let me share another screencast, this time the new code review system up and running, again on a Mac OS X. (Don't forget to set it to full screen, we recorded it in HD for your viewing pleasure!! :) ).



    Cool, isn't it?

    In fact now everyone using Plastic can enjoy from integrated code review, and what's even better: distributed code review since you can replicate reviews back and forth as they're always related to branches...
    Pablo Santos
    I'm the CTO and Founder at Códice.
    I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
    I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
    I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
    And I love simple code. You can reach me at @psluaces.

    4 comentarios: