Login
Register
Ingres.comNavigation
Learn About
Developing With
Ingres Talk
Information
Toolbox
Views
Subversion to Piccolo Command Mapping
From Ingres Community Wiki
| Action | Piccolo Command | svn command | Notes |
| Open a file for update | p open | N/A | svn retains a local copy that you can edit like any file in your file system. |
| Create client source tree | p label -p <label> > file; p get -l file | svn checkout <URL> | No svn equivalent to a piccolo label so it is not possible to pull a label that is at a given code cut off with some changes added and/or some changes removed. You can however pull a specific revision (in piccolo terms, head rev at a certain time). |
| Create label (tag file revisions according client workspace) | p label <label> | svn copy my-working-copy <URL>/<label> | svn copy actually has four different uses, including the ability to copy a working-copy tree to the repository. Basically, this is nothing else than creating a branch from the working-copy.
|
| Abandoning updates to a file | p release | svn revert | |
| Checking which files have been updated. | p opened OR p working; p need | svn status -u | svn status list details from the current directory down. You'll get no output if changes are in another branch of the source tree. Use 'svn status' <local_root>' to get full output. tmp files not under source control will be listed witha status of ? (Yuk, lots of clutter). -n is equivalent to piccolo -d for svn status. -u shows files that are newer on the server, i.e. the "p need" info. Example alias for bash/ksh: alias svnstat='svn status -u | grep -v '\''^?'\''' (all quotes are single quotes). |
| Updating the client subscription | p need > file ; p get -l file | svn update | 'svn update' will pull all files to head rev and integrate any local modifications to head rev. |
| Pull a specific file | p get file | svn update file | Note that svn moves the revision for the entire branch with every change. Revision x of a file may be exactly the same as revision y of a file. |
| Review changes to a file | p rcompare file | svn diff file | Note that svn gets diffs against the file revision held by your client, NOT HEAD REV. For head rev use 'svn diff -r HEAD file'. svn diff with no file argument will diff all files in and under the cwd. |
| Reserving a file for change | p reserve file | svn lock | A reservation lock can be released using 'svn unlock file'. Locks will automatically be released when submitting changes ('svn commit'). |
| Submitting a change | p sc | svn commit --<username> -m "Comment" | WARNING: svn commit will submit ALL changes in the client. To submit a subset of the modified files you must use the --targets FILE flag where FILE contains a list of files that make up the change, OR use the --changelist ARG (1.5 only) where ARG is a previously establish identifier that associated files have been tied to. OR, omit the -m, and edit the file list as part of creating the comment in an editor. |
| Add a file to a directory | p reserve -a | svn add <file> | |
| Remove a file | p reserve -d | svn delete <file> | |
| Move a file | delete + add | svn move <file> | |
| Add a directory | svn mkdir <dir> | ||
| Display change details | p describe <chg> | svn diff -c <chg> ; svn log -v -r <chg> <local_root> | May be a better way to do this. Diff gives the difs for each file modified, log gives the author, date details plus change description. WARNING: 'svn log' only reports details for files in or under the cwd. |
| Identify a group of associated files. | N/A. | svn cl MyBugOrProject <filelist> | The changelist can be used with 'svn commit' to only submit the files identified as part of MyBugOrProject |
| Obtain change history for a file | p filelog <file> | svn log -r BASE:HEAD -q <file> | Note that the revisions lists are the ones where this file actually changed. There will be gaps unless the file was changed in every code change submitted. |
| Obtain information about a file | p have | svn status <local_root> |
Issue list
The following issues are currently outstanding. They represent features, capabilities, or requirements that we haven't come to consensus for a solution yet.
1) History transfer
It is clear transfering the history from piccolo to a new tool is desirable. Availability of history is critical.
Options:
a) Keep piccolo around read only
The advantage of this is we have little work to do. We can keep track of who's accessed piccolo and decide on whether
b) Build a tool for transfering history out of piccolo
This is a big undertaking, but perhaps achievable. The precedent when migrating to piccolo was to leave some of the history behind. This was felt it would be too painful. Apparently it settled in the end and was no big deal.
It may be the case that after a year passes and the short term working history is in a new tool, people access piccolo less and less. After a few years, perhaps no one accesses it at all.
2) Release note tracking and management
We need a proper place to store data that will be processed to create release notes.
Options:
a) Store it in the bug tracker text with tags to markup the release notes text.
b) Create a new database and CLI/Web interfaces to bridge these systems
- Note that the release notes text will need to be updated in some cases.
3) Mapping issues to bugs and bugs to code changes
a) Choose a tool that has awareness of our CM tool and issue tracker
This may not be easy given limited hooks/plugins for service desk.
It may be easier if we chose to consolidate a single issue and bug tracker and ensure that tool has awareness of our CM tool.
b) Build our own layer that does this mapping.
4) EDBC Server (mainframe) SVN access
Currently, the EDBC Server code, which is not open source, is maintained on the mainframe in a home-grown code management/build system called ISLM. This system is extremely limited and does not even have version control. For that reason, the piccolo client was recently ported to the mainframe so that the EDBC source code be stored/maintained in Piccolo. Besides having the benefit of a real CM system, it provides the extra benefit of being able to more easily integrate changes from Ingres; this is less important now, but likely to be more important in the future. Anyway, the actual movement of source from ISLM to Piccolo is on hold until we determine what we are going to be doing with Ingres code (Piccolo, SVN or ???). With regards to an SVN client on the mainframe, there doesn't appear to be one currently. 3 approaches have come to mind based on research so far:
a) Port SVN client to the mainframe. SVN depends on other components:
- Apache Portable Runtime (APR) - OS/390 version exists, but not z/OS...some work needed but probably not too bad
- Neon - not sure what this is and/or how critical ... would need more research
- OpenSSL - This, or equivalent, is implemented on the mainframe.
b) Use svnkit which is a java implementation of the SVN client.
- Java on the mainframe is slow.
- May need to run under USS rather than native z/OS, which is slow and clumsy and uncertain of mapping of files from this to native z/OS files/libraries.
c) Use a "klunky?" setup using Linux shell scripts which FTP files from a Linux SVN environment to the mainframe.
BOTTOM LINE for EDBC server is that some porting of a client tool will be required. Since this is probably true for other CM clients being considered (such as Mercurial) as well, this is not considered to be a show-stopper or significant consideration for adoption of a CM system. Plus keep in mind that EDBC is still closed-source and that it doesn't currently use Piccolo anyway.
The EDBC client shares the Ingres code directly and runs on the same platforms (Windows, Unix and Linux, not VMS) as Ingres. Hence, the same tool chosen for Ingres will be fine for the EDBC client.
5) Managing different build lineups during support/maintenance
The way support manages patch content today in piccolo allows a single codeline with a different set of patches for each platform. For example:
Headrev for codeline contains patches A,B,C,D,E,F
Latest Linux build for 32 bit: A,B,C,F
Latest Linux build for 64 bit: A,B,E
Latest VMS build: A,C,E
etc. each platform can have a different set of patches
This works in piccolo as a patch developer can pull the latest label for that platform, add a new patch, and create a new label. In svn, the same concept maps to differenent branches for each platform which is a bit clunky. Some options will be added here soon.
