Archive for December 2009
While I was looking for a solution to backup my git repository, I started with the SyncToy. It was the tool I used on XP. Now on Windows 7, the offline files feature can sync network folders and files. On the web, there are Windows Live Sync and Window Live Mesh. They all can sync folders and files. So many tools and features, I am going to pick one by being picky.
SyncToy is easy to use, but it doesn’t support schedule. I am too lazy to to create scheduled tasks in windows.
Windows 7 Sync center can schedule syncs, but basically you are working on a network shared folder. I don’t want to write code on a shared folder. Plus git reports error when using UNC path, unless the shared folder is mapped to a drive.
Windows Live Sync syncs files between computers, not shared folders. Computers must be on the Internet and be running Live Sync program under my account. My wife is mainly using the other computer that I want to save a backup to. I need to create shares …
Live Mesh is similar to Live Sync. Further more, it actually copies files to its web storage. To have a backup in the cloud is a good option. No worries about my wife’s computer. I will chose Live Mesh. All I need to do is just to right click the folder and select “Add folder to Live Mesh …”
BTW, when right clicked, another menu showed up “Shared Folder Synchronization …”. What? Another sync tool, SharePoint Workspaces?
I want to copy my git repository to another computer for the purpose of backup. After installed the git on the other computer, I found out a SSH server is also needed on that Windows system. Fortunately followed this blog post, "8 ways to share your git repository", I used the shared folder option. It is not even needed to install git on remote computer.
The remote repository is a shared repository that I can push my branches to. This is great. But what I wanted is only to have a backup my repository. End of the day what I need is the Sync Toy.
Actually I have been playing the engine behind the sync toy for a while, the Microsoft Sync Framework. It seems that things come along together around the concept of disconnected and distributed. Git is. Sync is. It could be a big concept in application development.
I had a good impression about the Eclipse's Local History feature before, which allows me to view, compare and merge with my previously versions of the source code. Later on, I used an add-in for Visual Studio 2005/2008, called Visual Local History 2005. Now I started to use Git on my laptop. Suddenly I am able to do branching locally.
Branching used to be a scary thing that requires a lot of planning for server based source code management. E.g. In order to do a proper branching on Microsoft Team Foundation Server, we have to read, understand and follow a book, Team Foundation Server Branching Guidance. Git made it cheap and easy to do branching on local. This let us create as many as branches we want. Not only production and testing branches, but also experimental branches for features and try outs. I played it a little bit and here are some nice experiences.
One Repository and Switch Between Multiple Branchess
I created one repository for my solution which includes three projects to start with, a Silverlight class library, a Silverlight Application and a Web application to host Silverlight application. Then I created three branches, master, develop and tryout. In the tryout branch, I removed the web application project from the solution and made the Silverlight Application generate a test page instead.
Switching between develop and tryout branches (in terms of Git's terminology it is checkout), Visual Studio detects the solution file has been changed and will reload the solution file and source files accordingly. Git must be preparing/restoring files for the branches! No need to create workspaces and separated folders for branches! No need to mapping the working folders. One caveat though is that you cannot switch branch if there are pending commits.
Cherry-Picking and Mergee
I added all files before modifying the .gitignore file. The files in the bin and obj folders are included. To fix it, in tryout branch I deleted the two folders. Because I don't want to apply other changes back to the develop and master branches yet, I used the Git cherry-pick function to apply only the deletion back to the develop and master branches. Nice and easy. But to do it from the master branch is even easier.
For some reason the .pdb files weren't deleted (maybe I had the Visual Studio in debugging). They are still under source control. This is even easier to deal with. I switched to the master branch. Deleted the bin and obj folder again. Commit and Merged the deletion into the develop and tryout branch..
Next I am going to install Git on a desktop computer and push code from laptop.
Within the patterns & practices SharePoint Guidance, there are a few reusable components, such as Hierarchical Configuration, Logging and Service Locator. They are basic infrastructure for SharePoint applications. Here are some my thoughts.
1) The hint is that to start build any types of application, web application, Silverlight application and etc, the first thing is to get configuration, logging, service locator/dependency injection ready.
2) In .NET base class libray, there should be generaric interfaces, such as ILogger, IConfig for custom implementation, like the GeoAPI.NET, which provides OGC/ISO standards based interfaces to .NET GIS projects. Today, the ILogger defined in Microsoft.Practices.SPG.Common is useless to other LOB DLLs.
3) Compare to the Enterprise Library monster, Microsoft.Practices.SPG.Common is much lighter. But the ILogger and IConfigurationManager are coupled w/ SharePoint, and there is no dependency injection.
I am looking into the possibilities to implement dependency injection to SharePoint development, as I did for ASP.NET MVVM.
- basicHttpBinding – SOAP 1.1
- wsHttpBinding – SOAP 1.2 (looks like it is only good for .NET client)
- webHttpBinding – HTTP/REST
- for ASP.NET AJAX Client/JSON, in web.config created a new endpoint with address "/ajax", and defined the <endpointBehaviors> to have <enableWebScript />, now the URL …/xxx.svc/ajax/js and …/xxx.svc/ajax/jsdebug return proxy in Javacript. The proxy is used by the client template for data binding
- for REST, in web.config created a new endpoint with address "/xml" and defined the <endpointBehaviors> use <webHttp/>. now the [WebGet] attribute works for URL …/xxx.svc/xml/Id=123. [XmlSerializerFormat] was used to control the XML schema structure.