Search Results

Search found 3 results on 1 pages for 'cogmios'.

Page 1/1 | 1 

  • ClearCase: Copy old versions with Snapshot Views under Windows

    - by cogmios
    Using IBM Rational ClearCase: - I have only access to Snapshot Views so NO dynamic Views I want to copy ALL versions from a certain changeset to c:\temp. I have already listed the changeset versions in a file (couple of hundred of versions, I only need the latest one), I do not have a baseline over this older set. What I now have and does not work: #!/usr/bin/perl -w # # PROGRAM: copytest.pl $filename = "Design test123.doc"; $view = "D:\\AdminViews\\ABC_R1_READ_2\\ABCD002\\ABC_DESIGN\\BLA Framework\\P0\\"; $version = "\\main\\ABC_R1_READ\\1"; $printhet = 'cleartool find . -name "' . $filename . '" -version version(' . $version. ') -exec "cmd /c copy %CLEARCASE_XPN% D:\temp\%CLEARCASE_PN%"'; system($printhet);

    Read the article

  • Export Failed Element Log(s) after deliver?

    - by cogmios
    When a deliver has been performed I can rightlick an entry in the GUI version/element log and it displays me a popup with the element log. Quite handy. I now have a delivery with about 25 failed ones and a couple of hundred OK's. Sadly I can not sort on the column "status" so I have to make screenshots wherever I find a [!] to sit together with the specific team to find out if it is really ok to not deliver those. It would however be handy to have this list of element logs from a deliver so that I do not have to make screenshots or copy the contents of the popup box one by one but just have a list of the failed ones with the element log. Is there a way to export the element logs from a deliver (so the the ones that show up when you rightclick and choose "Display Element Log") and/or only the ones that gave failures?

    Read the article

  • ClearCase UCM Mainline Configuration Management Pattern Question

    - by cogmios
    A configuration management pattern question (using Rational ClearCase UCM) When I use the mainline approach I create new releases by: - create release 1 from mainline - on a certain moment baseline release 1, deliver release 1 to mainline - create release 2 from mainline - on a certain moment baseline release 2, deliver release 2 to mainline - create release 3 from mainline - etc... Works very nice because the pathname is /main/release 3/latest instead of /main/release 1/release 2/release 3/latest etc... However... when in release 1 are new elements that have to be propagated to later releases I can not use the mainline since the mainline is already on e.g. release 4. The only thing I can do is deliver/merge from release 1 directly to release 2. The bad thing is that the pathname then becomes /main/release 1/release 2/latest for that files (and possibly later releases). That is I think not in line with the mainline approach. What am I doing wrong?

    Read the article

1