Using Git to improve ClearCase workflow

Turbodad wrote:

> http://www.turbodad.com/2008/04/07/i...flow-with-git/
>
> Comments are welcome.

WTF?

How does this improve the CC workflow?
Which workflow are you talking about?
Despite CC, how would using two tools which exist for the same purpose make
life easier?
What are your problems with CC, anyway?

Sorry, I don't get your point.

Bye...

Dirk

Dirk Heinrichs wrote:
> Turbodad wrote:
>
>> http://www.turbodad.com/2008/04/07/i...flow-with-git/
>>
>> Comments are welcome.
>
> WTF?
>
> How does this improve the CC workflow?
> Which workflow are you talking about?
> Despite CC, how would using two tools which exist for the same purpose
> make
> life easier?
> What are your problems with CC, anyway?
>
> Sorry, I don't get your point.
His point is he doesn't understand Clearcase so he bashes it. Take, for
example:

1. no need to keep files checked out exclusively in ClearCase while I
work on a new feature or fix a bug;
2. no need to work in private ClearCase branch and merge using
ClearCase tools;
3. keeping my modifications (patches) as small as possible and always
based on the latest code;
4. ability to quickly branch code to test a new idea without anyone
noticing it;
5. ability to work disconnected (if I were to use a laptop, that
would be a killer feature);
6. by keeping my changes grouped and submitting them to ClearCase
together I can emulate changelist feature absent in ClearCase
(without this feature one can often expect broken builds due to
partial commits).

#1 above doesn't even make sense. You can check out or not check out
exclusively any file you want in Clearcase. With snapshot views you
don't even need to check out.

#2 doesn't make sense either. You don't have to work on a branch but
it's a good policy to do so. And Clearcase merge tools are excellent.

#3 has nothing to do with Clearcase or any other CMS.

#4 Clearcase supports this as well. The writer doesn't know what he's
talking about.

#5 Snapshot views give you this capability - have for years...

#6 UCM implements the concept of a changeset quite nicely.
--
ClearSCM, Inc.
Andrew DeFaria, President
Psychiatrists say that 1 of 4 people is mentally ill. Check three
friends. If they're OK, you're it.

Andrew DeFaria wrote:

> Dirk Heinrichs wrote:
>> Turbodad wrote:
>>>
http://www.turbodad.com/2008/04/07/i...flow-with-git/
>>>
>>> Comments are welcome.
>>
>> Sorry, I don't get your point.
>
> His point is he doesn't understand Clearcase so he bashes it.

I was well aware of this :-)

Bye...

Dirk

On Tue, 08 Apr 2008 18:40:41 +0200, Dirk Heinrichs wrote:
> Andrew DeFaria wrote:
>
>> Dirk Heinrichs wrote:
>>> Turbodad wrote:
>>>>
> http://www.turbodad.com/2008/04/07/i...flow-with-git/
>>>>
>>>> Comments are welcome.
>>>
>>> Sorry, I don't get your point.
>>
>> His point is he doesn't understand Clearcase so he bashes it.
>
> I was well aware of this :-)

Or, his organization doesn't understand Clearcase. It's hard to
understand it if everyone else uses it as an expensive RCS or CVS.

/Jorgen

--
// Jorgen Grahn \X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!

On Mon, 7 Apr 2008 17:38:09 +0100, Turbodad wrote:
> http://www.turbodad.com/2008/04/07/i...flow-with-git/
>
> Comments are welcome.

Same as my comments here back in February, related to "Using CVS and
Clearcase at the same time", Message-ID
<4063d60f-d33e-48f5-96d6-74c943ca4bcd@m78g2000hsh.googlegroups.com>.

I get suspicious when other developers hide their change history from
me, and deliver the whole feature as a blob when it's done. I don't
like that you use the phrase "without anyone noticing it".

/Jorgen

--
// Jorgen Grahn \X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew DeFaria schrieb:
| His point is he doesn't understand Clearcase so he bashes it. Take, for
| example:

I understand the OPs points quite well because I was in the same situation a
year ago: My group of 22 software engineers was using CC for many years
(personally I have 12+ years experience with it). When I first heard about git
and Mercurial (which is another impressing new VCS tool) and the general concept
of distributed version control it made me curious enough to give it a try. I was
(and still am) amazed how simple and lighting fast version control with these
tools can be. Due to the simpler UI (at least at that time) compared to git I
picked Mercurial as my VCS of choice. Because my co-workers still used ClearCase
I implemented a similar workflow as the OP. Fortunately I could convince them to
try Mercurial as well and we now retired our ClearCase installation completely.
|
| 1. no need to keep files checked out exclusively in ClearCase while I
| work on a new feature or fix a bug;
| 2. no need to work in private ClearCase branch and merge using
| ClearCase tools;
| 3. keeping my modifications (patches) as small as possible and always
| based on the latest code;
| 4. ability to quickly branch code to test a new idea without anyone
| noticing it;
| 5. ability to work disconnected (if I were to use a laptop, that
| would be a killer feature);
| 6. by keeping my changes grouped and submitting them to ClearCase
| together I can emulate changelist feature absent in ClearCase
| (without this feature one can often expect broken builds due to
| partial commits).
|
| #1 above doesn't even make sense. You can check out or not check out
| exclusively any file you want in Clearcase. With snapshot views you
| don't even need to check out.
I think what the OP talks about here is the difference between the
lock-modify-unlock model of CC compared to the copy-modify-merge model git,
Mercurial and many other VCS tools use. If you have used git or Mercurial
you will find the need to checkout a file (reserved or unreserved) before you
can edit it pretty annoying. Of course you could use a snapshot view but then
you turn CC really into an expensive CVS. Dynamic views are the main advantage
that CC offers over other VCSs IMHO.
|
| #2 doesn't make sense either. You don't have to work on a branch but
| it's a good policy to do so. And Clearcase merge tools are excellent.
|
The point here is, I guess, that in CC you have to create such a branch
explicitly and make sure that your config spec is correctly using it. In a DVCS
there is no need for that. You automatically get your private branch when you
clone a repository and start committing to it. Merging your changes with
upstream changes is very simple (no need for a 'findmerge' and the like).

| #3 has nothing to do with Clearcase or any other CMS.
|
Yes and no. My experience tells me that with Mercurial (and git) being so fast
and easy to use me and my co-workers tent to create small self-contained change
sets targeted to a single bug or feature. With CC it was always like: OK, I have
checked out some files for feature A but I will also fix bug B in this file and
add feature C in that file instead of checking them in and out again. People are
lazy (at least I am).

| #4 Clearcase supports this as well. The writer doesn't know what he's
| talking about.
Actually I don't understand what you refer to. If you use dynamic views and you
create a branch or check out some files this can be seen by anybody.
|
| #5 Snapshot views give you this capability - have for years...
A snapshot view gives you only one version of a file. A clone of a git or
Mercurial repo gives you the complete history. That's not the same.
|
| #6 UCM implements the concept of a changeset quite nicely.
I have to admit that I don't have much experience with UCM. I tried it a few
years ago and didn't like it at all. At least at that time I found it far too
complicated. I really would have liked to get the change set support but not for
the cost of adapting our whole workflow. With git and Mercurial change sets are
part of the tool design and are therefore supported in a natural way.

Just some experiences from a happy CC refugee,
Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIA33/YQUEVIa9IeIRAjQUAJ0en/7tMdXMr3qjxhkQ/by82T/TmwCggb7K
4YEjDAgnRdTM5M/IqWZl87o=
=nCpv
-----END PGP SIGNATURE-----

Peter Weseloh wrote:

> Andrew DeFaria schrieb:
> | His point is he doesn't understand Clearcase so he bashes it. Take, for
> | example:
>
> I understand the OPs points quite well because I was in the same situation
> a year ago: My group of 22 software engineers was using CC for many years
> (personally I have 12+ years experience with it). When I first heard about
> git and Mercurial (which is another impressing new VCS tool) and the
> general concept of distributed version control it made me curious enough
> to give it a try.

Hmm, isn't ClearCase the very first distributed version control system in
the market?

> I was (and still am) amazed how simple and lighting fast
> version control with these tools can be.

I still didn't find out how to switch my git workspace from Linus' tree to
Greg KH's and vice versa, and I've spend some hours on the matter. With CC
I can edit one line in my configspec.

> Due to the simpler UI (at least
> at that time) compared to git I picked Mercurial as my VCS of choice.

You should not forget that these tools are just that: Version Control
Systems. CC is far more.

> Because my co-workers still used ClearCase I implemented a similar
> workflow as the OP. Fortunately I could convince them to try Mercurial as
> well and we now retired our ClearCase installation completely.

What did you replace clearmake with?

> |
> | 1. no need to keep files checked out exclusively in ClearCase while I
> | work on a new feature or fix a bug;
> | 2. no need to work in private ClearCase branch and merge using
> | ClearCase tools;
> | 3. keeping my modifications (patches) as small as possible and always
> | based on the latest code;
> | 4. ability to quickly branch code to test a new idea without anyone
> | noticing it;
> | 5. ability to work disconnected (if I were to use a laptop, that
> | would be a killer feature);
> | 6. by keeping my changes grouped and submitting them to ClearCase
> | together I can emulate changelist feature absent in ClearCase
> | (without this feature one can often expect broken builds due to
> | partial commits).
> |
> | #1 above doesn't even make sense. You can check out or not check out
> | exclusively any file you want in Clearcase. With snapshot views you
> | don't even need to check out.
> I think what the OP talks about here is the difference between the
> lock-modify-unlock model of CC compared to the copy-modify-merge model
> git, Mercurial and many other VCS tools use.

I don't know what the OP's talking about at all.

> If you have used git or
> Mercurial you will find the need to checkout a file (reserved or
> unreserved) before you can edit it pretty annoying.

No, I don't. It's much harder to edit files by mistake, or even have them
overwritten accidentally, without noticing.

> Of course you could
> use a snapshot view but then you turn CC really into an expensive CVS.
> Dynamic views are the main advantage that CC offers over other VCSs IMHO.

Yes, they are. But you only get their full power if you also use clearmake
for building your software.

> |
> | #2 doesn't make sense either. You don't have to work on a branch but
> | it's a good policy to do so. And Clearcase merge tools are excellent.
> |
> The point here is, I guess, that in CC you have to create such a branch
> explicitly and make sure that your config spec is correctly using it.

So what? Provide a simple template to your users, will hardly be longer than
6 lines.

> In a
> DVCS there is no need for that. You automatically get your private branch
> when you clone a repository and start committing to it.

And as soon as it exists, anybody can commit to it. You can't do anything
against it. In CC, you can simply lock the branch type.

> Merging your
> changes with upstream changes is very simple (no need for a 'findmerge'
> and the like).

Well. There _is_ the need, it's just called differently.

> | #3 has nothing to do with Clearcase or any other CMS.
> |
> Yes and no. My experience tells me that with Mercurial (and git) being so
> fast and easy to use me and my co-workers tent to create small
> self-contained change sets targeted to a single bug or feature. With CC it
> was always like: OK, I have checked out some files for feature A but I
> will also fix bug B in this file and add feature C in that file instead of
> checking them in and out again. People are lazy (at least I am).

Tha's one of the biggest problem: People's lazyness. You can work this way
in CC, too. But when it comes to problems, you'll find out it would have
been better to avoid this laziness.

> | #4 Clearcase supports this as well. The writer doesn't know what he's
> | talking about.
> Actually I don't understand what you refer to. If you use dynamic views
> and you create a branch or check out some files this can be seen by
> anybody.

.... who explicitely selects the same branch in his configspec.

Users of mercurial or git or subversion can do the same, they can checkout
from my branch, if something has been committed to it. Here comes another
problem: Do you backup your mercurial workspaces. People tend to commit
only when they're finished with the task.

> |
> | #5 Snapshot views give you this capability - have for years...
> A snapshot view gives you only one version of a file. A clone of a git or
> Mercurial repo gives you the complete history. That's not the same.

So, what we are referring to is a replica, not a view?

> | #6 UCM implements the concept of a changeset quite nicely.
> I have to admit that I don't have much experience with UCM.

Me neither. But you don't need UCM to have changesets. We have defined that
all changes done on a particular branch is the changeset.

> Just some experiences from a happy CC refugee,

As a private person, I use monotone (I can't afford a CC license :-) ).
However, for enterprise use, I wouldn't recommend any such tool, unless it
comes with a build tool as powerfull as clearmake. BTW: There is _NONE_
today.

However, this all still doesn't explain why anybody would use one VCS on top
of another, no matter which ones.

Bye...

Dirk

On Apr 14, 9:52 pm, Dirk Heinrichs wrote:

> Hmm, isn't ClearCase the very first distributed version control system in
> the market?

Could have been.
How many replica can you have?
10?
Compare with 10000.

Branching/merging implicit, transparent.
With mercurial, you discover that you had been merging
when a conflict arises (when you pull somebody's code
which conflicts with yours).

Of course, nowhere is there the correct driver to discover
interesting code: derived object management.
People do not read diffs.
Nobody reads 10000 diffs.
So you must rely on rumours, and friends.

Marc

Marc Girod wrote:

> How many replica can you have?
> 10?

I don't know of any such limit.

Bye...

Dirk