-
Notifications
You must be signed in to change notification settings - Fork 0
SourceRepository
Since 2012, Sept. 7 the CSS sources are on github:
- https://github.com/ControlSystemStudio/cs-studio - Browse sources
-
git clone https://github.com/Control[[SystemStudio]]/cs-studio.git- Get copy of sources
Originally, the CSS sources were in a CVS repository at DESY, see http://css.desy.de, "Developer's Corner", "Get User Account at DESY".
In July 2010, most CSS sources moved to a Mercurial repository on Source Forge. Use this URL to browse the Mercurial repositories: http://cs-studio.hg.sourceforge.net/hgweb/cs-studio/
Fundamentally, you obtain a copy like this, using your Source Forge account name:
# Read-only
hg clone http://cs-studio.hg.sourceforge.net:8000/hgroot/cs-studio/cs-studio
# Read/write access
hg clone ssh://[email protected]/hgroot/cs-studio/cs-studio
Users at some laboratories whose IT security protects them from accessing non-standard HTTP ports like 8000 can unfortunately not use the read-only method. They can still browse the sources or use ssh.
You need to install the Mercurial software. Download it from http://mercurial.selenic.com/ which also offers nice introductions.
Windows users can download the TortoiseHg version of Mercurial which includes the "hg.exe" command-line tool but also GUI tools that integrate with the Windows file explorer.
The Mercurial command-line tools is similar but in many aspects easier to use than the CVS command-line tool because it automatically handles subdirectories.
Most of the time, using Mercurial from within Eclipse will be more convenient, but there might be some use for the Mercurial command-line tool, one of them being to verify your SSH access: read on.
- http://hgbook.red-bean.com/read/ - is a free online book which serves as an exhaustive guide for mercurial.
Linux and OS X already include SSH support. On Windows, install Putty to use PLINK.EXE instead of ssh.
For details, see http://www.codza.com/mercurial-with-ssh-setup-on-windows for info on the Putty setup for Windows. Make sure that there is no default setting in putty, that will cause plink to fail! Add -ssh option in mercurial.ini so that plink.exe will use SSH protocol.
Your computer needs to be able to connect to the repository server with ssh, which you can try as follows on Linux and OS X. On Windows, use plink.exe:
ssh [email protected]
The authenticity of host 'cs-studio.hg.sourceforge.net (216.34.181.121)' can't be established.
RSA key fingerprint is 86:7b:1b:12:85:35:8a:b7:98:b6:d2:97:5e:96:58:1d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'cs-studio.hg.sourceforge.net,216.34.181.121' (RSA) to the list of known hosts.
[email protected]'s password:
Welcome to *.hg.sourceforge.net
This is a restricted Shell Account
You cannot execute anything here.
Connection to cs-studio.hg.sourceforge.net closed.
When doing this for the first time, you will be prompted about the authenticity. It should ask for a password, and then disconnect as shown. The point is that you must be able to reach the server:
You should setup SSH key pairs to allow access to the Mercurial on Source Forge without having to type your password for every access. While this is certainly of advantage for the command-line access, it is at this time also required for HG Eclipse.
Go to your Source Forge account page, https://sourceforge.net/account/, select the 'Services' tab, and follow the instructions for registering a public ssh key. Now you should be able to connect to the repository server without authenticity warnings and without a password prompt:
ssh -i /path/to/my/sf_key [email protected]
Welcome to *.hg.sourceforge.net
This is a restricted Shell Account
You cannot execute anything here.
Connection to cs-studio.hg.sourceforge.net closed.
For Windows, use plink.exe instead of ssh.
Next, configure ssh to automatically use this key when connecting to the project. On Linux and OS X, add the following to your ~/.ssh/config file (create file if necessary):
Host cs-studio.hg.sourceforge.net
[[PreferredAuthentications]] publickey
[[IdentityFile]] /path/to/my/id_dsa_sourceforge
User YOUR_SF_ACCOUNT_NAME
On Windows, add this to a file mercurial.ini in your home directory:
[ui]
ssh="c:\Program Files\[[TortoiseHg]]\plink.exe" -i c:/css/priv.ppk -ssh
You can use TortoisePlink.exe that is included in TortoiseHg, or the plink.exe that comes with the basic Putty package.
You should now be able to connect to the sourceforge server with a simple ssh command:
ssh cs-studio.hg.sourceforge.net
Welcome to *.hg.sourceforge.net
This is a restricted Shell Account
You cannot execute anything here.
Connection to cs-studio.hg.sourceforge.net closed.
or with a simple hg command line:
hg clone ssh://cs-studio.hg.sourceforge.net/hgroot/...
In the end, you should be able to clone a repository from the command line using an SSH connection as shown above ("hg clone ssh://.....") without being prompted for your password.
The HG Eclipse plugin provides Eclipse 'Team' support for Mercurial, see http://www.javaforge.com/project/HGE
It seems best to not install from the update site, but instead copy the latest MercurialEclipse, i.e. the file
com.vectrace.[[MercurialEclipse]]_<some version>.jar
into your IDE's 'dropin' directory.
From http://www.javaforge.com/project/HGE, follow the links to "download the plugin jars and install manually from here: plugin directory". Will lead to http://hge.javaforge.com/mercurialeclipse-snapshots or http://javaforge.com/proj/doc.do?doc_id=76461. Locate a recent version (com.vectrace.MercurialEclipse_1.7.0.201006082155.jar ?), copy into your IDE's 'dropin' directory.
Older versions resulted in a slow refresh mechanism, missing or very slowly appearing decorators, or "history" showing info for the wrong file. There were also installation problems with the HG Eclipse update site. If you have a well running Eclipse RDP IDE setup, it updated all the HG Eclipse dependencies, including basic plugins like SWT to the 'latest', and then you lack the matching source plugins for source-level debugging. It further got confused when installing MercurialEclipse 1.6 into a fresh setup, because the update site will in addition install some hgeclipse 1.5 transition plugin, then claim you had 1.5 installed and should install MercurialEclipse 1.6 again.
Once installed, it might be necessary to configure MercurialEclipse to find the command-line version of hg, which might be /usr/local/bin/hg, via the Eclipse Preferences Team/Mercurial.
It's important to understand that you will 'clone' the whole mercurial repository into some directory. That directory is hierarchical, for example with subdirectories for 'core' components separate from site-specific project files. It will contain a copy of all sources, and in that directory tree you can also invoke the headless build or other operations. Eclipse can perform that 'clone' operation.
At the same time, Eclipse will not show all the sources in the clone. Neither will it show the directory hierarchy. Instead, the Eclipse workspace will only show the flat list of plugins that you decide to import into the workspace.
For example, the directory tree might look like this
/core/plugins/shared_lib
/applications/plugins/app1
/applications/plugins/app2
/products/site1/site1_office_product
/products/site1/site1_controlroom_product
/products/site2/site2_office_product
The workspace for a person working at site 2 might then look as follows, only showing the flat list of plugins of interest to that person:
shared_lib
app1
app2
site2_office_product
The 'clone', however, will have the same directory tree for both people.
To perform the clone in Eclipse:
- File/New/Other.../Mercurial/Clone repository using Mercurial
- Enter repository location like
ssh://cs-studio.hg.sourceforge.net/hgroot/cs-studio/cs-studio - Enter user name. In principle, also enter your Source Forge password, but at this time it does not work. You have to setup ssh key pairs.
- Clone destination: You could keep the defaults, but it might be better to un-check the default and instead pick a parent directory outside of the workspace.
- Clone directory name: This will be the name of the clone's directory tree. You might want to place it outside of your workspace because it will not show up in the workspace anyway. Eclipse will work OK if you place the clone directory in the workspace because during the initial clone it knows that it's the clone, not a directory that actually belongs to the workspace file. Later, however, if you have a need to re-create the workspace (delete .metadata, re-import the directory), Eclipse will be confused about finding a clone directory tree in the workspace, so it's best to keep the clone outside of the workspace directory.
- Press 'Next'
On the second page of the clone wizard you will be prompted for the "working directory revision", i.e. which version of the sources you want to actually use. Usually, pick the latest or "default".
On the third page of the clone wizard you will be able to select the plugins that you want to import into the workspace. You can either a. Select all plugins. That way you see all there is to see, which can be a lot. a. Select only the plugins that you need.
This stage is somewhat painful. Whatever you select, Eclipse will be busy for a while because it compiles everything that you selected, and at the same time the mercurial plugin tries to initialize some data for each imported plugin. Your IDE may actually run out of memory, or appear hung and the best solution may to kill it and open again. You may want to increment the amount of memory that the IDE uses: Look for the eclipse.ini file, section "-XX:MaxPermSize=256m" and "-Xmx512m" and increment those numbers.
If you only import the plugins that you actually need, this can be a little easier, but then there's the question of how to determine what you actually need.
To know what you need, you can look into the clone's products directory. For example, products/NSLS2 has files plugins.list and features.list that tell you what's needed for the NSLS2 product.
The SNS product has similar *.list files.
At a later time, you can import plugins from the clone's directory tree into the workspace via the usual File/Import/General/Existing Projects into Workspace. When doing that, assert that you do not check the option to "Copy projects into workspace". You do want the imported projects to show in the Workspace, but they must physically remain inside the cloned directory tree, not copied into the workspace directory.
The 'Team' operations in Eclipse are pretty much the same for Mercurial as they are for CVS. You can Commit, Update, Synchronize, view the History, apply tags, ... as in CVS.
What's different: Comments automatically apply to the whole change set, not just individual files. The change sets show movements and name changes of files.
The main difference: Commit and update operations affect the local Mercurial clone. In the distributed repository you can frequently commit changes while working on a project. Once a new feature 'works', you push the changes to the main repository at Source Forge.
In essence, the CVS 'commit' turns into a local 'commit' followed by a 'push'.
Similarly, the equivalent of a CVS 'update' is now a 'pull' from the Source Forge repository, then an 'update' from the local clone.
Just like CVS, Mercurial detects conflicts. Assume two people working on the same file. Somebody changes a line to
Hello Fred
and succesfully commits and pushes that change.
Meanwhile, you changed the same line to
Hello Dolly
You commit to your local clone of the repository, but when you try to push, you get an error
push creates new remote heads ...
Or you try to pull the latest from the remote repository, then update, which ends in an error ... crosses branches.
Both indicate the same issue: There is a conflicting change for the file. When you look at the Team/Show History, you see a graph with two heads: The "tip" has the "Hello Fred" change, but there is also a branch with the "Dolly" version.
What do do:
-
Team/Pull. Eclipse will by default automatically perform an Update, and that fails with "crosses branches". -
Team/Merge. You will be promped for the head with which to merge. If there's only one, just press "OK". - In the
Mercurial MergeView, open each conflicting file, handle the conflicts, then mark as "resolved". -
Team/Commit,Team/Push
What is new in Mercurial, compared to CVS, is the idea of change sets. If you change one file, but somebody else added another file, that is also considered a conflict, because the overall set of files changed, so you have to merge the changes into your copy of the fileset. The solution is again to pull, merge, commit, push, but since there are no conflicts within individual files, the merge step will be quicker.
To avoid conflicts, pull & update before changing files.
When you create a new plugin XYZ in Eclipse, you must uncheck the "Use default location" option which would locate your plugin sources in your workspace directory. Instead, browse to the desired location in the Mercurial clone directory tree, for example ..../applications/plugins/XYZ.
This page also describes adding projects (plugins) to a Mercurial repository: http://ekkescorner.wordpress.com/blog-series/git-mercurial/workflow-create-multi-project-repositories-hg/
- Start putty.exe, set host name as blank, port as 0, Session name (saved session) as cs-studio
- Go to proxy page to set your proxy. Then go back to session page to save this session.
- Edit mercurial.ini and add -load cs-studio' to the end of 'ssh=plink.exe ...
See