10

I have recently been thrown into learning ClearCase (I come from a background with git and svn -- I desperately miss them both :) ) and have been chewing on this one for a while: in a snapshot view, what is the difference between an update and a rebase?

I know there are differences (and honestly I have started ignoring "update" altogether, because it never seems to do what I want (which is to pull down changes that other devs have recently delivered (git pull, svn update))), I just do not see what the difference is (and the cc docs are less than helpful on the matter (for bonus points: any pointers to good cc resources (something akin to svn-book or the git man pages, for example))). Yes, that was one sentence, and half-dozen parentheticals.

mgalgs
  • 15,671
  • 11
  • 61
  • 74

4 Answers4

10

Update is strictly for snapshot view: see the difference between snapshot and dynamic view.

When you do a rebase, using a snapshot view, that operation (which changes the foundation baselines of the Stream associated with the view) will be completed by an update of said snapshot view.

If you want to get the development of other developers, you can do it with an update only of said developers have been checking their code in on the same branch than the one you are monitoring with your snapshot view.
If you are using UCM, those developers must have their view associated with the same Stream than the one used by your snapshot view.

Then, an update will allow you to get back (and merge if necessary) all the modifications done by your colleagues.
But that is assuming you don't use the "one Stream per developer model" (which I don't find very useful)

For a good first read:

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    Great, thanks for the info. I've seen quite a few of your cc answers on here... IBM should definitely be paying you ;) – mgalgs Mar 20 '11 at 04:24
9

In case we are not clear, a stream = a branch in common term.

For UCM, an update is typically only useful when working on a shared-stream, such that another developer could be checking in files on that stream that you are working on. In this scenario, you use "update" to pull the changes made by that developer on that same stream.

A rebase pulls changes made on the central integration stream that has been committed by different developers across your company from their respective streams. A commit from substream to integration stream is called a "deliver" which is the opposite of rebase.

kolslorr
  • 956
  • 1
  • 8
  • 16
6

Update just updates a snapshot view so that it matches the corresponding versions in ClearCase.

Rebase is for UCM projects - it merges changes from the latest recommended baseline in the integration stream into your personal development stream.

Normally you use update for snapshot views of non-UCM stuff, whereas you use rebase for UCM projects.

Paul R
  • 208,748
  • 37
  • 389
  • 560
  • I guess that would explain why update never seems to be all that useful (we use UCM). I guess the piece I still don't understand is "so that it matches the corresponding versions in ClearCase". What do you mean by "in clearcase"? I would think "things that have been delivered to the stream on which my view is based", but again that makes an update sound an awful lot like a rebase... – mgalgs Mar 18 '11 at 23:04
  • @mitch: update is only used with *snapshot* views, which are kind of static in nature, like a local copy of what's in ClearCase. When you update you get changes from ClearCase which are more recent than your snapshot, i.e. bringing it up to date. Rebase does much the same thing but it also merges from integration to development stream. – Paul R Mar 19 '11 at 08:20
  • I guess it was mostly the idea of shared dev streams vs. main integration stream that was confusing me, now it makes sense, thanks. – mgalgs Mar 20 '11 at 04:28
-1

From what I understand, Clearcase update is like a merge in git.

  • It pulls down changes and then adds them as a new commit on that branch.
  • The base label doesn't change.

A rebase on the other hand is just like a rebase in git.

  • If you rebase to another label, then it's like rewriting your history to show that that branch was made from this new label.
  • This allows you to continue development on a feature branch and then before you release your changes you can rebase your branch to the latest official label.
jlouzado
  • 442
  • 3
  • 17