This website uses browsing/session and functional cookies to ensure you get the best experience. Learn More

Committing changes to the hardware repository

From Wiki for iCub and Friends
Jump to: navigation, search

Changes are committed by following certain procedures. In particular, the CAD commits are not very well supported by SVN. Changes should be agreed with the maintainers and pros/cons discussed before committing them. Debugging changes or documentation fixes do not need to follow this procedure unless for synchronizing the commit of binary files.

Proposal: maintaining platforms with SVN

There is a tentative to maintain the status of all the iCub hardware platforms by using branches of the iCubPlatform SVN repository. Here is a description of how this information can be maintained and modified exploiting the SVN repositories. This procedure hasn't been realized yet and could be modified in the future.

  1. Versions trunks: we will create different trunks corresponding to the different versions of the robot. In particular, for the version 1.1 of the iCub a trunk named iCubPlatform1.1 is already available at the URL Other trunks will be created in the future in the same location with appropriate names, e.g.
  2. Individual robot branches: each time drawings are sent to the machineshop for producing a new iCub version x.y, a branch of the current iCubPlatformx.y repository should be created (the assumption here is that the repository contains exactly the information about drawings sent to the machineshop). This branch should be named with the usual standard, e.g. if the robot is the first one to be used in Genova then the branch will be called iCubPlatformGenova01. This branch, should be left unmodified as long as no modifications/updates are performed on the physical robot. The URL of this branch will be, e.g.
  3. Upgrades selection based on branches differences: when the iCubCity01 comes back to the IIT for being updated, a list of available updates will be retrieved by comparing the iCubPlatformCity01 branch with the appropriate version trunk. As an example, if we want to update iCubCity01 to the version 1.1 of the iCub, a list of necessary modifications will be retrieved by comparing with This comparison can be performed automatically with SVN (see Comparing URL branches and trunk for instructions). The list of modified, added and deleted files should be checked carefully, and the updates to be performed on iCubCity01 should be decided on the basis of this list.
  4. Individual robot branches alignment: once the list of upgrades is confirmed, these upgrades should be physically realized on the robot. For each upgrade physically realized on iCubCity01, the corresponding file in iCubPlatformCity01 should be aligned correspondingly. This alignment has to be performed file-by-file with the with "svn commit" command in the iCubPlatformCity01 branch.

Note for SVN advanced users

The alignment described in Point 4. should be performed, if possible, with the "svn merge" command first. The "svn merge" will try to merge the trunk and the branch versions (since iCubPlatform is mainly composed of binaries, this command works only if the trunk version and the branch version haven't been modified in parallel. This is the case if the iCubPlatformCity01 hasn't been modified but only the iCubPlatformx.y has been modified. However, there are cases in which the iCubPlatformx.y and the iCubPlatformCity01 have to be modified in parallel; in these cases the "svn merge" will ask the user to resolve the conflict). In any case, when the iCubPlatformCity01 has been aligned with the new iCubCity01 robot, a commit of the modified files should be performed.

Personal tools