The Plastic SCM blog

How to install Plastic SCM 4.0 without system requirements restrictions

Hi, all:

As you might already know, Plastic SCM 4.0 comes with SQLServer CE 4.0 as the default backend in Windows. We decided to replace our good-old friend Firebird with this one to avoid undesired collisions with existing Plastic SCM 3.0 installations, since Plastic SCM 4.0 uses a different database schema that is not directly upgradeable.

On the other hand, Plastic SCM 4.0 minimum software requirements have been lifted to meet those of SQLServer CE 4.0 (check this link: http://www.microsoft.com/download/en/details.aspx?id=17876#system-requirements), which is a bit annoying, specially if you will customize your db.conf file to use a different backend after the installation / upgrade process.

Strictly speaking, Plastic SCM 4.0 requirements still are .NET Framework 2.0 SP2 for the server and .NET Framework 2.0 for the client (we finally moved our client to .NET Framework 2.0, hurray!), so if you want to avoid all the system requirements just open a CMD console (or shell in Linux) and type the following in a single line:

PlasticSCM-4.0.xxx.yyy-windows-installer.exe --nocheckrequirements true

where xxx.yyy is the release number you are trying to install. Please, take into account that if the system requirements are not met, Plastic SCM may not work correctly.

Thanks for reading and enjoy Plastic SCM 4.

4 3 2 1... launch

It has been an hectic season but we made it and released 4.0 last 17th. There has been several great things, but look at the videos: we had Robert C. Martin (of CleanCode and CleanCoders fame) and Steve Berczuk (THE Branching Patterns book) as keynote speakers!! Awesome, isn't it? http://www.plasticscm.com/plastic4launch/index-4.html Now looking forward talking, blogging and "demoing" the new release to the world! :) Thanks everyone for your support so far. We're a small, highly committed team achieving great things! :) Thanks!

Git merge vs the world

I’ll be talking about git merge system again, one of the strongest on the planet, and how a good merge system can unlock a new world of possibilities for developers facing complex refactors. And then, I’ll tell you how to break it. And what can be done.

Refactor and merge

What does refactor have to do with merge? Aren’t merging and refactors on different planets?

Not at all: you’re working on a refactor and then you need to move Class.java to a new package. It happens, doesn’t it?

But while you’re working on your refactor, I’ll be tweaking Class.java.

Ok, now refactor has to do with merging, and if you’re avoiding this situation it only means one thing: you don’t have a proper SCM (we could argue but, ok, tell me you do not need a mouse, a good IDE…).

The good, the bad and the ugly

Now you’ve to merge the previous scenario. What will happen?
  • Git (and of course my beloved Plastic SCM) will do the right thing: you get the rename plus the change. This IS what you expect.
  • SVN and the old fashioned pack (the bad and ugly) will, at best, end up with two files: the “old” Class.java with my changes plus yours, without my changes, on your destination location. Crazy.

    Let’s break it

    Let’s do something else: you move and modify Class.java. But I do the same… moving it (of course!) to a different location.

    Don’t do this at home with SVN: ok, the movie is over from the non-dvcs/non-merging scms, let’s focus on the real mergin machines.

    Git it!

    How does Git handle it?
    $ git commit -a -m "initial"
    Created initial commit ced4e21: initial
     1 files changed, 181 insertions(+), 0 deletions(-)
     create mode 100644 foo.cs
    
    $ git branch task001
    $ git checkout task001
    Switched to branch "task001"
    $ vi foo.cs
    $ git mv foo.cs bar.cs
    $ git commit -a -m "change on task001 + rename"
    Created commit d3c6970: change on task001 + rename
     2 files changed, 181 insertions(+), 181 deletions(-)
     create mode 100644 bar.cs
     delete mode 100644 foo.cs
    

    First move and change, let's go to the second.

    $ git checkout master
    Switched to branch "master"
    $ vi foo.cs
    $ git mv foo.cs moo.cs
    $ git commit -a -m "change on master + rename"
    Created commit 4644cb7: change on master + rename
     2 files changed, 182 insertions(+), 181 deletions(-)
     delete mode 100644 foo.cs
     create mode 100644 moo.cs
    
    $ git merge task001
    CONFLICT (rename/rename):
    Rename "foo.cs"->"moo.cs" in branch "HEAD" 
    rename "foo.cs"->"bar.cs" in "task001"
    Automatic merge failed; 
    fix conflicts and then commit the result.
    
    Ok, git nows about but... how does it handle it?
    $ git status
    # On branch master
    # Changed but not updated:
    #
    #       unmerged:   bar.cs
    #       unmerged:   foo.cs
    #       unmerged:   moo.cs
    #       modified:   moo.cs
    #
    
    no changes added to commit
    
    $ ls
    bar.cs  moo.cs
    
    Ooooops! The files are not merged and you’ve to solve the conflict yourself!!!

    Plastic it!

    Is there a better way?

    Yes: the dvcs should:

  • ask you: which rename do you prefer? (or any other option)
  • help you solve the rename
  • merge the files

    And that’s what Plastic SCM does.

    I’m happy to say that we’re launching Plastic SCM 4.0 today at www.plasticscm.com/launch... Join now! Superheroes already did http://plasticscm.com/heroestalk

  • Real Time Web Analytics