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.

This is how I use the synch view

Monday, August 15, 2011 Pablo Santos 2 Comments

Hi there,
How is it going with the 4.0 beta?
I’m going to start posting about what’s new in 4.0 and how you can use it to make things easier.
Today I’m going to talk about the “sync view”.

What’s the sync view all about?


The sync view is a very simple yet powerful functionality in 4.0 that enables you to connect two different repositories (which can “live” in different servers, separated by oceans, running on different OS, using different database backends… well, the usual) and check what’s need to be updated on each of them.

How does the sync view work?


Very simple: you define a “source repository” which is the one you “connect to” to drive the process. For instance, if you’re working in a distributed way, your “source server” will be your laptop and your “source repo” the repository you want to work with.
Then you define a “destination” repo as the place to synchronize with. Following with my disconnected scenario, your laptop will host your source repo and your company’s plastic server will host the “destination repo”.
Is it clear? Once you’ve selected the two, the sync view will connect to them and figure out what changes need to be pulled (from dst to src) or pushed (from src to dst).
Note: you know, if you just define the src repo and dst repo differently, the operation will have a different meaning.

Many scenarios supported


Well, as you read above the sync view is so simple and flexible that it is possible to support many different scenarios. We like to define them as follows:
  • Distributed developer: he will have his laptop or desktop as “source” and will typically have one “destination” server, the “master copy” (your office central server if you prefer). Optionally he could have more “destinations” to collaborate with other peers instead of restricting his pushing and pulling to a single server.
  • Multi-site environment: a company with two or more facilities, each of them running a plastic server. One of them will be the source and other the destination and sync will happen among them.
  • Distributed integrator: a network of distributed plastic servers (each of them running on each developer’s computer) and the sync view defined on the integrator’s machine as a way to be able to “pull” from all the contributors on a controlled way.

    As you can see, the “sync view” is a rather simple tool although it can enable really powerful business scenarios.

    Having a mirror server



    This is my case: I have a “master server” at the office, currently running on a W2k8 machine named “Diana” and with a SQL Server backend.
    I have other servers on my network and that’s why I have 3 different “sync configurations” as you can see below.




    I have one to synch my laptop with “Diana”, a second one to synch “Diana” with an Oracle powered Plastic server, and the third one, the one I’ll be focusing on today, which syncs “Diana” with “Eunomia”, a Firebird embedded Plastic SCM server running on a tiny VM.
    Once I click on “Diana-Eunomia” sync config I can see the following details:



    It tells me there are “outgoing” csets from “Diana” to “Eunomia”, which basically means “Eunomia” will need some sync.
    If I click to get the detailsl I see:



    Which details the branches that will be synched during the process. Actually these branches are going to be “pushed” from “Diana” to “Eunomia”.
    Finally I can click on a given branch and view which changesets need to be pushed:



    The good thing (excellent IMO) is that now you can click on a cset and check the differences… even when it is remote (you’re not directly connected to that server at all!). It enables “replication preview” which we all missed with 3.0… didn’t we?

    Wrapping up


    There’s a real bunch of things on 4.0 but the sync view is really one of the important features, extremely simple, but really helpful and powerful. 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.

    • Pablo Santos

    2 comments:

    1. Louis van TonderFebruary 8, 2012 at 3:49 PM

      Hey, great entry. I would like to know tho, si tehre no way to syn (all repo's on server a, with all repo's on server b). Basically, a silent allways on replication. Causing local users to server a, to always get updated copies locally form server a, and local users from server b, to allways get local copies from server b. I.E> no fata updating over a distributed link, but allways getting it from the local server? For any given repo?

      Can this be achieved?

      ReplyDelete
    2. Pablo SantosFebruary 8, 2012 at 5:13 PM

      Hi Louis,

      What you're asking for has been suggested already and it is on the roadmap: http://plasticscm.uservoice.com/forums/15467-general/suggestions/2475919-add-the-same-synchronize-all-functionality-to-th

      We're also about to publish our "replikate" command, which is a wrapper on top of our current cm replicate able to do what you're asking for. Our plan is to blog about it next week or so.

      In the meantime: it is not difficult to script it out using "cm find changeset" + "cm replicate" :P

      ReplyDelete

    Subscribe to: Post Comments (Atom)