Loading ...
Sorry, an error occurred while loading the content.
 

Re: clearcase eclipsed files are lost

Expand Messages
  • Brandon Metcalf
    ... There is no reason in ClearCase to intentionally eclipse a file element or to have one eclipsed to have write access. If you are getting eclipsed
    Message 1 of 10 , Mar 1, 2002
      Rainer.Stransky@... writes:

      || i am working in a development enviroment und hp-ux and clearcase.
      ||
      || In special cases a file in clearcase has to be made to view private and after
      || this file is eclipsed (in do not exactly know what this means in terms of a f
      || system).

      There is no reason in ClearCase to intentionally eclipse a file element
      or to have one eclipsed to have write access. If you are getting
      eclipsed elements, you are doing something wrong.

      Write access to elements is achieved by checking out the element which
      gives you a view private file, but doesn't eclipse anything.

      Brandon
      --
      And stop calling me Shirley
      --Doctor Rumack, Airplane
    • Rainer Stransky
      ... Thanks, that helps me a lot. But without a joke. I have to work in a development enviroment, in which all checkouts (in other views, by other guys) are
      Message 2 of 10 , Mar 1, 2002
        Brandon Metcalf wrote:

        > Rainer.Stransky@... writes:
        >
        > || i am working in a development enviroment und hp-ux and clearcase.
        > ||
        > || In special cases a file in clearcase has to be made to view private and after
        > || this file is eclipsed (in do not exactly know what this means in terms of a f
        > || system).
        >
        > There is no reason in ClearCase to intentionally eclipse a file element
        > or to have one eclipsed to have write access. If you are getting
        > eclipsed elements, you are doing something wrong.
        >
        > Write access to elements is achieved by checking out the element which
        > gives you a view private file, but doesn't eclipse anything.
        >

        Thanks, that helps me a lot.

        But without a joke. I have to work in a development enviroment, in which all
        checkouts (in other views, by other guys) are locked.
        So there is no chance for me to do a small quick change on a source without that
        tricky workaoround to get a eclipsed private file by:
        mv file.cc file.cc.priv
        cleartool co .
        cleartool rm file.cc
        mv file.cc.priv file.cc
        cleartool unco .

        That all will be done in a nice perl scirpt. All guys here in this enviroment are
        working that way.

        So my warranted question is, how to setup vim (if possible) to avoid losing the
        file, by open it with vim6.0

        I am not sure, but i think that behaviour was another one with vim5.4 !?

        Rainer

        >
        > Brandon
        > --
        > And stop calling me Shirley
        > --Doctor Rumack, Airplane
      • Brandon Metcalf
        Rainer.Stransky@alcatel.de writes: But without a joke. I have to work in a development enviroment, in which all checkouts (in other views, by other guys)
        Message 3 of 10 , Mar 1, 2002
          Rainer.Stransky@... writes:

          '' But without a joke. I have to work in a development enviroment, in which all
          '' checkouts (in other views, by other guys) are locked.
          '' So there is no chance for me to do a small quick change on a source without t
          '' tricky workaoround to get a eclipsed private file by:
          '' mv file.cc file.cc.priv
          '' cleartool co .
          '' cleartool rm file.cc
          '' mv file.cc.priv file.cc
          '' cleartool unco .
          ''
          '' That all will be done in a nice perl scirpt. All guys here in this enviroment
          '' working that way.
          ''
          '' So my warranted question is, how to setup vim (if possible) to avoid losing t
          '' file, by open it with vim6.0

          I realize that doesn't solve your vim problem, but you are creating the
          situation by using a broken workflow. Why do you need to work in a view
          other than your own? That's the whole point of a view; it's supposed to
          be your workspace.

          If you absolutely have to share a view, then make them group writable by
          setting your umask to 002 when the view is created.

          Even if I'm not understanding you correctly, the fact that you are
          using this Perl script to achieve the commands above demonstrates that
          your process is broken.

          Brandon
          --
          And stop calling me Shirley
          --Doctor Rumack, Airplane
        • Gary Johnson
          ... Ditto what Brandon said. We do multiple-developer development all the time without stepping on each other and never have to go through the hoops that you
          Message 4 of 10 , Mar 1, 2002
            On Fri, Mar 01, 2002 at 12:52:09PM -0600, Brandon Metcalf wrote:

            > I realize that doesn't solve your vim problem, but you are creating the
            > situation by using a broken workflow. Why do you need to work in a view
            > other than your own? That's the whole point of a view; it's supposed to
            > be your workspace.

            > Even if I'm not understanding you correctly, the fact that you are
            > using this Perl script to achieve the commands above demonstrates that
            > your process is broken.

            Ditto what Brandon said. We do multiple-developer development all the
            time without stepping on each other and never have to go through the
            hoops that you are. If you want to make a quick change to a locked
            file, check out an unreserved copy until the other guy checks in his
            changes. If you have multiple people working on the same set of files
            at the same time, each person should really be checking out each file
            onto his private branch first. That way the /main/LATEST version is not
            locked. As each person finishes his changes, he first checks his file
            into his private branch, then merges any parallel changes from the main
            branch onto his private branch, fixes anything that broke, and merges
            the combined changes back to the main branch. ClearCase is designed for
            just this type of development and used properly it works very well.

            Gary

            --
            Gary Johnson | Agilent Technologies
            garyjohn@... | Spokane, Washington, USA
          • Michael P. Soulier
            ... They re forcing us to transition to it at work, and initial trials are not good. They basically said what you did. Mike -- Michael P. Soulier
            Message 5 of 10 , Mar 1, 2002
              On 01/03/02 Ron Aaron did speaketh:

              > Ah, ClearCase! Sure, it's expensive, but at least it's slow!!

              :)

              They're forcing us to transition to it at work, and initial trials are not
              good. They basically said what you did.

              Mike

              --
              Michael P. Soulier <msoulier@...>, GnuPG pub key: 5BC8BE08
              "...the word HACK is used as a verb to indicate a massive amount
              of nerd-like effort." -Harley Hahn, A Student's Guide to Unix
            • Ron Aaron
              ... The problem isn t really Clearcase per-se. The problem is that the dynamic view requires a *lot* of network traffic, and when the network isn t super
              Message 6 of 10 , Mar 1, 2002
                Michael P. Soulier <michael.soulier@...> writes:
                >
                > They're forcing us to transition to it at work, and initial trials are not
                >good. They basically said what you did.


                The problem isn't really Clearcase per-se. The problem is that the 'dynamic
                view' requires a *lot* of network traffic, and when the network isn't super
                reliable and *very* fast, it doesn't support very many users each with a
                dynamic view, each doing compiles. At GoXXXXX, where I recently was a victim
                of downsizing, we had 60 developers banging on our 100MBit network. We *used*
                to complain that the CVS update was slow. Hah! The *regular build* with
                Clearcase was three to four times slower, depending on network usage.

                It's not a bad product, not at all -- just be careful how you use it!

                Of course now, I would be happy to have a *job*, even one working with
                Clearcase :-|

                Best regards,

                Ron
              Your message has been successfully submitted and would be delivered to recipients shortly.