Using Git to improve ClearCase workflow
Turbodad
Comments are welcome.
--
Turbodad
http://www.turbodad.com/
Dirk Heinrichs
> http://www.turbodad.com/2008/04/07/improving-clearcase-workflow-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
Andrew DeFaria
- no need to keep files checked out exclusively in ClearCase while I work on a new feature or fix a bug;
- no need to work in private ClearCase branch and merge using ClearCase tools;
- keeping my modifications (patches) as small as possible and always based on the latest code;
- ability to quickly branch code to test a new idea without anyone noticing it;
- ability to work disconnected (if I were to use a laptop, that would be a killer feature);
- 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).
#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.
Dirk Heinrichs
> Dirk Heinrichs wrote:
>> Turbodad wrote:
>>>
http://www.turbodad.com/2008/04/07/improving-clearcase-workflow-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
Jorgen Grahn
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 <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
Jorgen Grahn
> http://www.turbodad.com/2008/04/07/improving-clearcase-workflow-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...@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".
Peter Weseloh
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-----
Dirk Heinrichs
> 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
Marc Girod
> 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
Dirk Heinrichs
> How many replica can you have?
> 10?
I don't know of any such limit.
Bye...
Dirk
Andrew DeFaria
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-----
Andrew DeFaria
Of course I haven't the foggiest clue what was said here... ;-)
But that's been par for the course...
Dirk Heinrichs
> Of course I haven't the foggiest clue what was said here... ;-)
*LOL* Thumbs up! Both of them ;-)
Bye...
Dirk
Marc Girod
> I don't know of any such limit.
But in practice?
Every new replica creates an additional burden to
every other existing one.
The default configuration will have every server
create a packet for every replica it knows.
restricting to known replicas is dangerous: it
forces you to know too much.
The stupid schemes usually in place in big
companies will set up a central police.
The more you control, the less you manage.
What is the maximum number of replica for a
given vob you have ever met.
I repeat: 10?
Marc
Marc Girod
But neither of you means what he writes that in a
spirit or clarification, isn't it?
Both of you are happy with not understanding,
and blaming me for it, right?
Do I understand correctly what you are saying?
If so, there's nothing I can do.
Marc
Peter Weseloh
Hash: SHA1
Dirk Heinrichs schrieb:
| 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.
|
I'm using Mercurial so I can help you here. Like Mercurial git has a very active
community. Maybe you could get help from them? In Mercurial it would be 'hg
update' followed by the change set id you want to switch your workspace to. But
maybe I missed your point.
|> 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.
|
That's true. They are VCSs. I haven't claimed anything else, did I? I don't
actually know what you mean with 'far more'? In case you mean clearmake, please
~ see below.
|> 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?
|
That actually was a big problem (so be prepared for a long answer :-).
When we discussed to switch away from CC in my group this was a strong argument
against doing so. We came up with the following list of features a potential
clearmake replacement would need (in a addition to the general 'make/gmake'
features) (in the order of importance).
1. Reliable incremental builds with correct dependency tracking.
2. Possibility to exactly identify from which source file versions a executable
was build.
3. Distribute parallel builds to various machines in the LAN.
4. Sharing of object files between users to avoid rebuilds.
Currently we use 'gmake' (mainly because we could reuse the makefiles).
For point 4 we use 'ccache' with a shared cache dir. Works OK.
For point 3 we use 'distcc'. Works very well (IMHO better then clearmake).
For point 2 we put the changeset id of the repository into the executable as a
'what' string. If we want to know from which source file versions the exe was
build we simply update the repo to that changeset id. Works very well (IMHO
better then CCs config records).
Point 1 is(was) the most difficult one. We added a 'depend' to our makefiles,
but for unknown reasons we still sometimes get incorrect incremental builds so
we have to do a clean build. One reason might be clock skew between the machines
and another one seams to be related to interrupted builds.
In the last weeks I created a new build system based on 'scons' and (up to now)
it works reliable and fast (despite other comments I read about it) so point 1
is solved as well, I hope.
So, finally, we don't miss clearmake anymore. But I have to admit it was quite a
way to go.
OK, your are right, that's a matter of personal preference. I should have
written 'I found it annoying'. With Mercurial, running a 'hg status' tells me in
a split-second which files have been modified, 'hg diff' shows me exactly what
has been modified. That's good enough for me.
|> 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.
Agreed.
|
|> |
|> | #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.
|
That's exactly what we did (although it was 10 lines long, if I remember
correctly :-). In addition we had a script to automate the template handling and
some CC triggers to enforce our work flow. With Mercurial we don't need that
anymore.
|> 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.
|
I don't understand what you mean. If the branch only exist in my private repo
nobody can commit to it. If I decide to publish it why would I want to stop
others to commit to it?
|> 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.
Yes, of course, merging is also required in Mercurial (and git and any other VCS
I know). What I meant is that it is easier to use and harder to do wrong (and
MUCH faster). At least that is my and my colleagues opinion, but 'easier' and
'harder' depend on personal preference and experience, of course.
|
|> | #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.
|
Absolutely agreed. But that's what happened all the time. I'm simply saying that
with Mercurial I don't see that happening anymore (or at least far less).
|> | #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.
|
I thought about 'xlsvtree' and friends here. But maybe I misunderstand the point
(the question is what the OP means with 'without anyone noticing').
| 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.
|
In our setup at work the private repos+workspaces are on what our IT guys call a
'high availability/high reliability' storage. So, yes, they are in backup (at
least we pay our IT department for it :-)
|> |
|> | #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?
|
I never used CC replicas but I guess they are more difficult to create then a
Mercurial repo clone ('hg clone').
|> | #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.
That's what we did as well (again with some scripts to make developers lives
easier).
|
|> Just some experiences from a happy CC refugee,
|
| As a private person, I use monotone (I can't afford a CC license :-) ).
Another nice thing about a open source VCS: I can use the same tool at home as I
use at work. I can even put our source code repo(s) on a USB stick (or send me
bundles via email or pull via ssh) and do some work/experiments at home and
later transfer what turned out to be useful back to work. Mercurial will ensure
that everything stays consistent.
| 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.
After we have now used Mercurial more then half a year in production with 22
local developers plus developers from universities and sub-contractors
distributed around Europe we are quite happy with it. Regarding clearmake,
please see my comments above.
|
| However, this all still doesn't explain why anybody would use one VCS on top
| of another, no matter which ones.
The OP made this quite clear IMHO. He has to use CC for the project he is
working on but wants to use git, because in his opinion it's the better tool.
That's why he came up with the workflow he describes on that web page. It gives
him (and maybe others) the option to try out other VCSs without disturbing the
project.
As far as I understand the OP, if he would have the choice, he would completely
switch to git (like we switched to Mercurial).
|
| Bye...
|
| Dirk
Bye,
Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFICfrrYQUEVIa9IeIRAkG3AKCqHeTM3SMUqkEc1PvoBgK1vjSkOACeN/ak
D40Nz16AA/4dOzIfano4zWQ=
=ruml
-----END PGP SIGNATURE-----
Dirk Heinrichs
> On Apr 16, 9:07 pm, Dirk Heinrichs <dirk.heinri...@online.de> wrote:
>
>> I don't know of any such limit.
>
> But in practice?
>
> Every new replica creates an additional burden to
> every other existing one.
Which burden do you mean? Slightly increased disc space and computing power
needs on the VOB server?
> The default configuration will have every server
> create a packet for every replica it knows.
Nope. The default configuration doesn't create packages at all. It's the
admin who tells CC when to create sync packages for which replica(s). If we
didn't have our cronjobs set up for replication, we wouldn't sync at all.
> restricting to known replicas is dangerous: it
> forces you to know too much.
I always thought knowledge was good. And yes, I want to know were my
packages are synced to. This way I can avoid receiving the same changes
multiple times, from different replicas.
> The stupid schemes usually in place in big
> companies will set up a central police.
> The more you control, the less you manage.
Sure, one has to find the right balance. OTOH, controling can easily be
automated.
> What is the maximum number of replica for a
> given vob you have ever met.
>
> I repeat: 10?
Even less. So what? With careful sync planning you can reduce possible
problems that stem from a high number of replicas to a minimum (I'm still
not convinced there will be any).
Bye...
Dirk
Marc Girod
> Which burden do you mean?
I explained which just below.
But let's detail.
> Slightly increased disc space and computing power
> needs on the VOB server?
There are 24 hours hours a day.
This cannot easily be increased.
> Nope. The default configuration doesn't create packages at all.
Right/wrong.
Indeed, nothing is enabled by default.
But some scripts are provided, and some scheduler jobs.
They need to be enabled, correct.
But their behaviour is what I described.
> It's the admin who tells CC when to create sync packages for
> which replica(s). If we didn't have our cronjobs set up for
> replication, we wouldn't sync at all.
If you use cronjobs, instead of the scheduler, it is
that you designed a proprietary solution in replacement
for the one provided, and used by most of the other
customers (including inside Nokia).
This doesn't mean that your jobs are better, or even good.
> I always thought knowledge was good. And yes, I want to know were my
> packages are synced to. This way I can avoid receiving the same changes
> multiple times, from different replicas.
I also think knowledge is good.
Only this applies to human knowledge, not to information
held in a system. In this case, this means depending
upon volatile information, in a way requiring frequent
updates. Any addition of a replica somewhere, any
move or rename, will force you to take actions.
This is a limiting factor of the scalability of the system.
I guess your scripts create one packet per replica
(per enabled replica, OK).
They don't create shared packets, right?
Your network sends all the packets, with all this
duplicated information, right again?
I have seen the shipping server crossing the firewalls
sending 14 copies of the same oplogs to subcontractors
in India (that was my worst case scenario, 7 replicas
inside, and 2 at the subcontractor).
The solution the company took, because of the
incompetence of the administrators to understand
the scripts I had written, was to buy more bandwidth.
This wouldn't scale to 10000.
> Sure, one has to find the right balance. OTOH, controling can easily be
> automated.
No. Precisely, not in general.
It can often in simple cases, which thus become
artificially complex.
> Even less. So what?
So you have no experience of what a really
distributed SCM system might be.
Think of getting rid of snapshot views (dirty hack),
and replacing them with sites.
> With careful sync planning you can reduce possible
> problems that stem from a high number of replicas to a minimum (I'm still
> not convinced there will be any).
'Careful planning'...
That's an oxymoron. It is always careless planning.
Planning means restricting the future for lack of
understanding the past.
It is careful on the contrary to design the system
so that no special 'care' is further required: so that
additional replicas do *not* set additional burden
to the existing ones. This is called scalability.
It is possible. For ClearCase MultiSite, I have done it.
Now, it doesn't solve all the problems of ClearCase
not being a good distributed solution.
Dynamic views on remote sites are still not on a par
with views on the local ones.
[Some people with no understanding of scalability
issues have requested from IBM that DOs would
be replicated--I take this as obviously stupid]
Marc
Andrew DeFaria
On Apr 18, 9:50 pm, Dirk Heinrichs <dirk.heinri...@online.de> wrote:
Andrew DeFaria wrote:But neither of you means what he writes that in a spirit or clarification, isn't it?
Of course I haven't the foggiest clue what was said here... ;-)*LOL* Thumbs up! Both of them ;-)
Both of you are happy with not understanding, and blaming me for it, right?
I suspect English is not your first language. While not a crime you do know that English is the language being spoken here (and is pretty much the language of most business). And you've chosen to converse in English. Now if you want help or wish to analyze something in particular I, and I bet others, wouldn't mind giving you our opinion or correction as native English speakers. But don't be surprised if people find your words or usage a bit odd or don't understand you. And don't blame us for your poor English communication skills!
Do I understand correctly what you are saying?
If so, there's nothing I can do.
Andrew DeFaria
| No, I don't. It's much harder to edit files by mistake, or even have them
| overwritten accidentally, without noticing.
|
OK, your are right, that's a matter of personal preference. I should have
written 'I found it annoying'.
I've been consulting in the realm of Clearcase for many years at many companies. I've seen various usages. And I agree, some are very annoying. But even Mercurial has annoying features and implementations I would guess.
Forcing usage of your personal favorite software simply because you find others annoying is effectively making everybody have to use your personal favorite software. VCS is not something used in isolation - everybody has to get on board with the VCS being used - otherwise you might as well not even use one! I would hope that your decision to use Mercurial over CC was based much more on merit than "I found [CC] annoying"!
With Mercurial, running a 'hg status' tells me in a split-second which files have been modified, 'hg diff' shows me exactly what has been modified. That's good enough for me.
| 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.
|
I don't understand what you mean. If the branch only exist in my private repo
nobody can commit to it.
If I decide to publish it why would I want to stop
others to commit to it?
|> 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.
Yes, of course, merging is also required in Mercurial (and git and any other VCS
I know). What I meant is that it is easier to use and harder to do wrong (and
MUCH faster). At least that is my and my colleagues opinion, but 'easier' and
'harder' depend on personal preference and experience, of course.
|
|> | #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.
|
Absolutely agreed. But that's what happened all the time. I'm simply saying that
with Mercurial I don't see that happening anymore (or at least far less).
What I find often happens is that when you have a lot of developers, perhaps geographically dispersed, large software with many components, complicated systems, etc., users of Clearcase tend to make a more process heavy CM process with enforcement that everybody needs to follow. This keeps things in line. Now while this may seem annoying or harder, in the end, getting the right bits out the right door, it pays for itself.
The problem is no company is completely big, has completely large, complex software to manage. Or rather they do, but they also have a whole bunch of smaller software, in house processes and scripts and other smaller software projects that unfortunately have to compete with and utilize that heavy and heavily enforced CM process. Companies would be wise to recognize that both types exist in their organization and should provide various CM controls, some heavy and some much lighter. Many companies fail to do this and this makes small projects and engineers in them resent the whole CM process thrust upon them.
Dirk Heinrichs
> On Apr 19, 3:44 pm, Dirk Heinrichs <dirk.heinri...@online.de> wrote:
>
>> Which burden do you mean?
>
> I explained which just below.
> But let's detail.
>
>> Slightly increased disc space and computing power
>> needs on the VOB server?
>
> There are 24 hours hours a day.
> This cannot easily be increased.
I know. But how is this related?
>> Nope. The default configuration doesn't create packages at all.
>
> Right/wrong.
> Indeed, nothing is enabled by default.
> But some scripts are provided, and some scheduler jobs.
> They need to be enabled, correct.
> But their behaviour is what I described.
That's why we don't use them.
>> It's the admin who tells CC when to create sync packages for
>> which replica(s). If we didn't have our cronjobs set up for
>> replication, we wouldn't sync at all.
>
> If you use cronjobs, instead of the scheduler, it is
> that you designed a proprietary solution in replacement
> for the one provided, and used by most of the other
> customers (including inside Nokia).
> This doesn't mean that your jobs are better, or even good.
Oh, they are :-)
> Any addition of a replica somewhere, any
> move or rename, will force you to take actions.
That's simply false. Sometimes I find out about a new replica of a VOB by
accident. And then I still don't take any action. I don't even care. I only
start to care if this replica causes trouble somehow, which happens not so
often.
> I guess your scripts create one packet per replica
> (per enabled replica, OK).
If enabled means "the ones we sync with", then yes. Because sync frequences
and method vary between different sites (due to different connectivity)
> They don't create shared packets, right?
We currently don't have the need/use case.
> Your network sends all the packets, with all this
> duplicated information, right again?
For the reasons listed above and for the VOBs affected, yes.
> I have seen the shipping server crossing the firewalls
> sending 14 copies of the same oplogs to subcontractors
> in India (that was my worst case scenario, 7 replicas
> inside, and 2 at the subcontractor).
So it was setup wrong?
> The solution the company took, because of the
> incompetence of the administrators to understand
> the scripts I had written, was to buy more bandwidth.
Sorry, I can't judge wether this was good or not, I don't know the case.
> This wouldn't scale to 10000.
Let's get serious again. You'll hardly find VOBs where the number of
replicas is higher than 100. And even this estimation is far over the top.
There's no case for 10000 replicas.
>> Sure, one has to find the right balance. OTOH, controling can easily be
>> automated.
>
> No. Precisely, not in general.
> It can often in simple cases, which thus become
> artificially complex.
>
>> Even less. So what?
>
> So you have no experience of what a really
> distributed SCM system might be.
So a system is only to be called "distributed" when it is distributed across
enough sites?
> Think of getting rid of snapshot views (dirty hack),
> and replacing them with sites.
Since I never used snapshot views, getting rid of them is beyond my mind :-)
>> With careful sync planning you can reduce possible
>> problems that stem from a high number of replicas to a minimum (I'm still
>> not convinced there will be any).
>
> 'Careful planning'...
> That's an oxymoron. It is always careless planning.
> Planning means restricting the future for lack of
> understanding the past.
Or the contrary. Opening oportunities for the future _because_ the (errors
of the) past was (were) well understood.
> It is careful on the contrary to design the system
> so that no special 'care' is further required: so that
> additional replicas do *not* set additional burden
> to the existing ones. This is called scalability.
You still didn't tell what burden that is (or I didn't get it).
> It is possible. For ClearCase MultiSite, I have done it.
So do we.
> Now, it doesn't solve all the problems of ClearCase
> not being a good distributed solution.
There are some, but they have hardly anything to do with number of replicas
or syncing them.
> Dynamic views on remote sites are still not on a par
> with views on the local ones.
I don't understand. Why would I care about views on the remote sites?
> [Some people with no understanding of scalability
> issues have requested from IBM that DOs would
> be replicated--I take this as obviously stupid]
I fully agree.
Bye...
Dirk
Marc Girod
> I suspect English is not your first language.
Quite obviously it is not.
But you could not convince me this is the
problem here--despite the occasional language
error (e.g. there was an unfortunate extra 'that'
in a sentence you quoted).
Marc
Andrew DeFaria
On Apr 19, 5:22 pm, Andrew DeFaria <And...@DeFaria.com> wrote:
I suspect English is not your first language.Quite obviously it is not.
But you could not convince me this is the problem here--despite the occasional language error (e.g. there was an unfortunate extra 'that' in a sentence you quoted).
Dirk Heinrichs
> Dirk Heinrichs schrieb:
> | Peter Weseloh wrote:
> |
> |> 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.
> |
> I'm using Mercurial so I can help you here. Like Mercurial git has a very
> active community. Maybe you could get help from them? In Mercurial it
> would be 'hg update' followed by the change set id you want to switch your
> workspace to. But maybe I missed your point.
I know it's possible with other VCS', did it many times. But I was only
talking about git. And with git, the above seems to be impossible. Or I'm
just to stupid. I don't know.
> | You should not forget that these tools are just that: Version Control
> | Systems. CC is far more.
> |
> That's true. They are VCSs. I haven't claimed anything else, did I? I
> don't actually know what you mean with 'far more'? In case you mean
> clearmake, please ~ see below.
Yes, that's what I meant. The trio MVFS, clearmake, dynamic view.
> | What did you replace clearmake with?
> |
> That actually was a big problem (so be prepared for a long answer :-).
> When we discussed to switch away from CC in my group this was a strong
> argument against doing so. We came up with the following list of features
> a potential clearmake replacement would need (in a addition to the general
> 'make/gmake' features) (in the order of importance).
>
> 1. Reliable incremental builds with correct dependency tracking.
> 2. Possibility to exactly identify from which source file versions a
> executable was build.
> 3. Distribute parallel builds to various machines in the LAN.
> 4. Sharing of object files between users to avoid rebuilds.
>
> Currently we use 'gmake' (mainly because we could reuse the makefiles).
> For point 4 we use 'ccache' with a shared cache dir. Works OK.
> For point 3 we use 'distcc'. Works very well (IMHO better then clearmake).
As a Gentoo Linux user, I have tried both ccache and distcc, but they didn't
give me any improvements. Let's look how distcc works:
1) It splits up compilation into preprocessing and compilation, where
preprocessing happens on localhost, only compilation is done on remote
machines.
2) All the linking is done on localhost.
3) It only works for C/C++ -> Everything else is done on localhost.
The only advantage of this is that you don't need to keep all header files
on the remote machines, only the compiler needs to be available.
OTOH, with clearmake:
1) Compilation jobs are not artificially split.
2) Linking can happen everywhere.
3) It's language independant.
> For point 2 we put the changeset id of the repository into the executable
> as a 'what' string. If we want to know from which source file versions the
> exe was build we simply update the repo to that changeset id. Works very
> well (IMHO better then CCs config records).
So it records the way any particular object file was built? You can create a
makefile out of it (for use outside clearcase/clearmake)? Wow, that's
great.
> Point 1 is(was) the most difficult one. We added a 'depend' to our
> makefiles, but for unknown reasons we still sometimes get incorrect
> incremental builds so we have to do a clean build. One reason might be
> clock skew between the machines and another one seams to be related to
> interrupted builds.
Clock skew can be avoided by using NTP.
> In the last weeks I created a new build system based on 'scons' and (up to
> now) it works reliable and fast (despite other comments I read about it)
> so point 1 is solved as well, I hope.
I once tried scons, but I didn't (and still don't) like python. Now I use
omake (the other one :-) ) where I can't use clearmake.
> So, finally, we don't miss clearmake anymore. But I have to admit it was
> quite a way to go.
I can imagine. I wouldn't even dare to make a proposal like this ;-)
> |> 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.
> |
> I don't understand what you mean. If the branch only exist in my private
> repo nobody can commit to it. If I decide to publish it why would I want
> to stop others to commit to it?
Because they interfere with my work. A third person checks out this branch
to try out the changes, and then comes back and asks "Hey, what did you do?
It's all crippled!", just because somebody else commited something stupid
to my branch.
> |> 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.
> Yes, of course, merging is also required in Mercurial (and git and any
> other VCS I know). What I meant is that it is easier to use and harder to
> do wrong (and MUCH faster). At least that is my and my colleagues opinion,
> but 'easier' and 'harder' depend on personal preference and experience, of
> course.
Agreed.
> | 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.
> |
> Absolutely agreed. But that's what happened all the time. I'm simply
> saying that with Mercurial I don't see that happening anymore (or at least
> far less).
OK.
> |> | #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.
> |
> I thought about 'xlsvtree' and friends here.
Well, we cannot read your thoughts. But this is the most harmless case. With
the version tree browser, others can look at what your branch, but to
actually use it, they need to take some explicit action.
> But maybe I misunderstand the
> point (the question is what the OP means with 'without anyone noticing').
I can only guess: Two people working on the same branch, in different
dynamic views. What one checks in is immediately visible in the other view
(because their conficspecs need to be similar or even identical).
> | 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.
> |
> In our setup at work the private repos+workspaces are on what our IT guys
> call a 'high availability/high reliability' storage. So, yes, they are in
> backup (at least we pay our IT department for it :-)
Good to know :-)
> I never used CC replicas but I guess they are more difficult to create
> then a Mercurial repo clone ('hg clone').
Creating a VOB replica in CC is a push operation, not pull. It can only be
initiated from an already existing replica. They are not anonymous.
> |> Just some experiences from a happy CC refugee,
> |
> | As a private person, I use monotone (I can't afford a CC license :-) ).
> Another nice thing about a open source VCS: I can use the same tool at
> home as I use at work. I can even put our source code repo(s) on a USB
> stick (or send me bundles via email or pull via ssh) and do some
> work/experiments at home and later transfer what turned out to be useful
> back to work. Mercurial will ensure that everything stays consistent.
What I do at home is usually totally unrelated to my work, so I don't care.
As I wrote, for private things, I use monotone, with omake as build tool.
> | 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.
> After we have now used Mercurial more then half a year in production with
> 22 local developers plus developers from universities and sub-contractors
> distributed around Europe we are quite happy with it. Regarding clearmake,
> please see my comments above.
> | However, this all still doesn't explain why anybody would use one VCS on
> | top of another, no matter which ones.
> The OP made this quite clear IMHO. He has to use CC for the project he is
> working on but wants to use git, because in his opinion it's the better
> tool. That's why he came up with the workflow he describes on that web
> page. It gives him (and maybe others) the option to try out other VCSs
> without disturbing the project.
So he creates himself more work and is less productive because he has to
know and use two tools for the same purpose?
> As far as I understand the OP, if he would have the choice, he would
> completely switch to git (like we switched to Mercurial).
That's for sure.
Bye...
Dirk
tatyana
> > Of course, nowhere is there the correct driver to discover
> > interesting code: derived object management.
> > People do not read diffs.
On Apr 18, 10:01 am, Andrew DeFaria <And...@DeFaria.com> wrote:
> Of course I haven't the foggiest clue what was said here... ;-)
Dear Andrew,
you are probably well aware of the quite powerful ClearCase
functionality: derived objects creation? And you have probably also
noticed the lack of the proper tool support for the derived objects
management, which has been limited mostly to config records diffs
only, and there has been no sign (for years) of the further ClearCase
development to enable any more sophisticated management.
It's not the first time you hear about this, is it? But even if so,
this is the first time indeed I see this topic would provoke such an
uncontrollable insulting rage:
On Apr 19, 5:22 pm, Andrew DeFaria <And...@DeFaria.com> wrote:
> I suspect English is not your first language.
Oh dear, what an exhibition....
Tanya.
Dirk Heinrichs
> you are probably well aware of the quite powerful ClearCase
> functionality: derived objects creation? And you have probably also
> noticed the lack of the proper tool support for the derived objects
> management, which has been limited mostly to config records diffs
> only, and there has been no sign (for years) of the further ClearCase
> development to enable any more sophisticated management.
Besides winkin, lsdo, rmdo, catcr, diffcr and the scrubbers what else do you
need?
Bye...
Dirk
Peter Weseloh
Hash: SHA1
Note: I deleted parts of the conversation because it became very difficult to
right IMHO. I hope that's OK.
Dirk Heinrichs schrieb:
| Peter Weseloh wrote:
|
|> I'm using Mercurial so I can help you here.
Uups, I meant "I can't help you here" . Sorry!
| I know it's possible with other VCS', did it many times. But I was only
| talking about git. And with git, the above seems to be impossible. Or I'm
| just to stupid. I don't know.
Just for my own curiosity I had a look at http://git.kernel,org in the meantime.
Maybe this is useful information for you (or, if you aready know, sorry for the
noice).
If I understand it right the Linux kernel sources are maintained in multiple git
repositories.
http://www.kroah.com/log/linux/howto.html explains how they are related and how
changesets are transfered between them. So if you want to look at e.g.
linux-2.6.git (Linus' kernel tree) and linux-2.6.22.y.git (2.6.22-stable kernel
tree maintained by Greg Kroah-Hartman) you simply clone both into separated
directories and then use 'cd' to switch between them. BTW I just used git to try
this out and it makes me feel stupid as well (the same feeling I had last year
when I first tried it). One of the reasons in my case is that Mercurial and git
have the same command names for (slightly) different things. Too bad, but the
curse of open source, I think.
| As a Gentoo Linux user, I have tried both ccache and distcc, but they didn't
| give me any improvements. Let's look how distcc works:
|
| 1) It splits up compilation into preprocessing and compilation, where
| preprocessing happens on localhost, only compilation is done on remote
| machines.
| 2) All the linking is done on localhost.
| 3) It only works for C/C++ -> Everything else is done on localhost.
|
| The only advantage of this is that you don't need to keep all header files
| on the remote machines, only the compiler needs to be available.
|
| OTOH, with clearmake:
|
| 1) Compilation jobs are not artificially split.
| 2) Linking can happen everywhere.
| 3) It's language independant.
That's true. Still I see a significant speed improvement compared to clearmake.
Maybe that's related to not using dynamic views anymore? I don't know and,
actually, I don't care anymore.
BTW I made some experiments not using distributed build at all. I cloned our
repos to a local disk of a (quite powerful) server and did a clean parallel
build ('gmake -j 8') with disabled distcc. And to my surprise that was even
faster! I guess that shows that the build process is mostly I/O and not CPU
bound, at least for our exes.
|> For point 2 we put the changeset id of the repository into the executable
|> as a 'what' string. If we want to know from which source file versions the
|> exe was build we simply update the repo to that changeset id. Works very
|> well (IMHO better then CCs config records).
|
| So it records the way any particular object file was built? You can create a
| makefile out of it (for use outside clearcase/clearmake)? Wow, that's
| great.
Oh, you (deliberately?) misunderstood me. As I wrote, it solves our point 2, not
more and but also not less. Why would I want more then that, anyhow? The way how
the exes are build is described in the makefiles (or Sconscript files) and they
are, of course, version controlled as well. We also don't need to create a
makefile 'for use outside clearcase/clearmake' because we ARE already outside
clearcase/clearmake. Remember :-)?
BTW we also put the changeset id(s) into the log files our exes produce. By
looking at a log file we can now exactly identify from what sources the exe was
build that produced that log. Without any additional overhead!
|> Point 1 is(was) the most difficult one. We added a 'depend' to our
|> makefiles, but for unknown reasons we still sometimes get incorrect
|> incremental builds so we have to do a clean build. One reason might be
|> clock skew between the machines and another one seams to be related to
|> interrupted builds.
|
| Clock skew can be avoided by using NTP.
Right, I know. Our IT guys claim that NTP is in use. They showed me a
complicated hierarchy of company internal NTP servers. I guess, something is
wrong with that. Fortunately with scons that's no problem for us anymore because
it does not rely on timestamps.
|> In the last weeks I created a new build system based on 'scons' and (up to
|> now) it works reliable and fast (despite other comments I read about it)
|> so point 1 is solved as well, I hope.
|
| I once tried scons, but I didn't (and still don't) like python. Now I use
| omake (the other one :-) ) where I can't use clearmake.
I'm python newbie, but for me as a C++ hacker it feels more 'at home' then
writing a Makefile.
|> So, finally, we don't miss clearmake anymore. But I have to admit it was
|> quite a way to go.
|
| I can imagine. I wouldn't even dare to make a proposal like this ;-)
It pays off in the end (and it's fun) I found out. Be brave :-)!
|> |> 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.
|> |
|> I don't understand what you mean. If the branch only exist in my private
|> repo nobody can commit to it. If I decide to publish it why would I want
|> to stop others to commit to it?
|
| Because they interfere with my work. A third person checks out this branch
| to try out the changes, and then comes back and asks "Hey, what did you do?
| It's all crippled!", just because somebody else commited something stupid
| to my branch.
I still don't get it. If you are not yet ready, don't publish (e.g. push) your
commits.
After you have published your changesets that third person could easily see who
committed on top of it and blame that guy.
You can even sign your changesets using gpg if you want. But maybe I don't
understand the workflow you have in mind.
|> But maybe I misunderstand the
|> point (the question is what the OP means with 'without anyone noticing').
|
| I can only guess: Two people working on the same branch, in different
| dynamic views. What one checks in is immediately visible in the other view
| (because their conficspecs need to be similar or even identical).
I think about the following: The OPs article refers to another web page (i.e.
http://www.littleredbat.net/mk/blog/story/63/). There the statement is made that
CC 'discourages experimental branching as streams are centralized, limited and
public'.
If you want to create a new branch in CC you first have to create a new 'branch
type' on all affected VOBs, right? This 'branch type' is visible to everybody.
If you have, say, 20 developers each with 5 different experimental branches you
and up with 100 branch types plus the 'official' ones. I can imagine that a CC
admin (or your co-workers) would not like that and that's what the OP refers to,
I guess. Of course, I might be wrong.
|> I never used CC replicas but I guess they are more difficult to create
|> then a Mercurial repo clone ('hg clone').
|
| Creating a VOB replica in CC is a push operation, not pull. It can only be
| initiated from an already existing replica. They are not anonymous.
Thanks for the information. For us replicas where not an option for multi-site.
We never could have convinced the Universities we work with to buy CC licenses.
Also for our sub-contractors that was no-no.
|> Another nice thing about a open source VCS: I can use the same tool at
|> home as I use at work. I can even put our source code repo(s) on a USB
|> stick (or send me bundles via email or pull via ssh) and do some
|> work/experiments at home and later transfer what turned out to be useful
|> back to work. Mercurial will ensure that everything stays consistent.
|
| What I do at home is usually totally unrelated to my work, so I don't care.
OK, but you can understand that for me it's a useful property I do care about,
right?
| Bye...
|
| Dirk
Regards,
Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFIC0DpYQUEVIa9IeIRAhaaAJ4h/BRHBAJnD8WlZkNrPa4QSe78fwCdFYir
qT5wmIHwrZvMDgZ5fGY2Sek=
=oC38
-----END PGP SIGNATURE-----
tatyana
> Besides winkin, lsdo, rmdo, catcr, diffcr and the scrubbers what else do you
> need?
For example, functionality to analyze hundreds of config record
hierarchies for the purposes other than winking, e.g. for comparing
two different tests.
Tanya.
Andrew DeFaria
On Apr 18, 10:01 am, Andrew DeFaria <And...@DeFaria.com> wrote:
Of course I haven't the foggiest clue what was said here... ;-)Dear Andrew,
you are probably well aware of the quite powerful ClearCase functionality: derived objects creation?
And you have probably also noticed the lack of the proper tool support for the derived objects management, which has been limited mostly to config records diffs only, and there has been no sign (for years) of the further ClearCase development to enable any more sophisticated management.
It's not the first time you hear about this, is it?
But even if so, this is the first time indeed I see this topic would provoke such an uncontrollable insulting rage:
On Apr 19, 5:22 pm, Andrew DeFaria <And...@DeFaria.com> wrote:
I suspect English is not your first language.Oh dear, what an exhibition....
Dirk Heinrichs
But that is already provided. You just need to assemble it.
In two different views do either this:
ct catcr -r my_top_level_do >~/cr_<view_tag>
or this:
ct catcr `find . <all my DOs>` >~/cr_<view_tag>
and then compare both with xcleardiff.
HTH...
Dirk
Dirk Heinrichs
> Note: I deleted parts of the conversation because it became very difficult
> to right IMHO. I hope that's OK.
Yes, that's fine.
> Dirk Heinrichs schrieb:
> | Peter Weseloh wrote:
> |
> |> I'm using Mercurial so I can help you here.
> Uups, I meant "I can't help you here" . Sorry!
Didn't even notice :-)
> If I understand it right the Linux kernel sources are maintained in
> multiple git repositories.
That's my understanding, too.
> http://www.kroah.com/log/linux/howto.html explains how they are related
> and how changesets are transfered between them. So if you want to look at
> e.g. linux-2.6.git (Linus' kernel tree) and linux-2.6.22.y.git
> (2.6.22-stable kernel tree maintained by Greg Kroah-Hartman) you simply
> clone both into separated directories and then use 'cd' to switch between
> them.
That's the thing I don't like. You have two repositories for the same thing.
> | As a Gentoo Linux user, I have tried both ccache and distcc, but they
> | didn't give me any improvements. Let's look how distcc works:
> |
> | 1) It splits up compilation into preprocessing and compilation, where
> | preprocessing happens on localhost, only compilation is done on remote
> | machines.
> | 2) All the linking is done on localhost.
> | 3) It only works for C/C++ -> Everything else is done on localhost.
> |
> | The only advantage of this is that you don't need to keep all header
> | files on the remote machines, only the compiler needs to be available.
> |
> | OTOH, with clearmake:
> |
> | 1) Compilation jobs are not artificially split.
> | 2) Linking can happen everywhere.
> | 3) It's language independant.
> That's true. Still I see a significant speed improvement compared to
> clearmake.
That's true. But I prefer _correct_ builds over fast ones.
> BTW I made some experiments not using distributed build at all. I cloned
> our repos to a local disk of a (quite powerful) server and did a clean
> parallel build ('gmake -j 8') with disabled distcc. And to my surprise
> that was even faster!
That's what I meant. The process of splitting the compilation into different
steps and transfering (only) part of it to remote machines can't be faster.
> |> For point 2 we put the changeset id of the repository into the
> |> executable as a 'what' string. If we want to know from which source
> |> file versions the exe was build we simply update the repo to that
> |> changeset id. Works very well (IMHO better then CCs config records).
> |
> | So it records the way any particular object file was built? You can
> | create a makefile out of it (for use outside clearcase/clearmake)? Wow,
> | that's great.
> Oh, you (deliberately?) misunderstood me.
No. I was referring to the "better than config records" part.
> |> Point 1 is(was) the most difficult one. We added a 'depend' to our
> |> makefiles, but for unknown reasons we still sometimes get incorrect
> |> incremental builds so we have to do a clean build. One reason might be
> |> clock skew between the machines and another one seams to be related to
> |> interrupted builds.
> |
> | Clock skew can be avoided by using NTP.
> Right, I know. Our IT guys claim that NTP is in use. They showed me a
> complicated hierarchy of company internal NTP servers. I guess, something
> is wrong with that. Fortunately with scons that's no problem for us
> anymore because it does not rely on timestamps.
One question: I don't remember anymore what scons does in case just a
comment (or whitespace) in a source file was changed. Does it recompile the
source file and then find out that the resulting object file is the same as
before, avoiding the unneeded re-linking of the exe or lib, or does it do
the linking?
> |> |> 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.
> |> |
> |> I don't understand what you mean. If the branch only exist in my
> |> private repo nobody can commit to it. If I decide to publish it why
> |> would I want to stop others to commit to it?
> |
> | Because they interfere with my work. A third person checks out this
> | branch to try out the changes, and then comes back and asks "Hey, what
> | did you do? It's all crippled!", just because somebody else commited
> | something stupid to my branch.
> I still don't get it. If you are not yet ready, don't publish (e.g. push)
> your commits.
Sometimes I want other people to try out intermediate version or my work.
> After you have published your changesets that third person could easily
> see who committed on top of it and blame that guy.
Yeah, that's true. What you have the hassle of finding out and cleaning up.
Would be better to prevent such things from happening at all.
> You can even sign your changesets using gpg if you want. But maybe I don't
> understand the workflow you have in mind.
Signing still doesn't prevent somebody else from modifying the branch after
I have published/commited it. Locking does. Or think subversion: A tag is
nothing else than a directory. So you publish a new official version of
your software, creating a new tag for it (in SVN this means "make a cheap
copy in another directory, named with the tag). If somebody checks out from
this directory and commits back to it, he has modified the released
software. That is not allowed to happen. Don't know if SVN has a mechanism
to prevent this, though. In CC, you just lock the label type after
labeling.
> I think about the following: The OPs article refers to another web page
> (i.e. http://www.littleredbat.net/mk/blog/story/63/). There the statement
> is made that CC 'discourages experimental branching as streams are
> centralized, limited and public'.
Hmm, I'm afraid don't understand this.
> If you want to create a new branch in CC you first have to create a new
> 'branch type' on all affected VOBs, right?
Yes. BTW: Use of AdminVOBs makes this an easy one. Type creation is then
done only once.
> This 'branch type' is visible to everybody. If you have, say, 20
> developers each with 5 different experimental branches you and up with 100
> branch types plus the 'official' ones. I can imagine that a CC admin (or
> your co-workers) would not like that and that's what the OP refers to, I
> guess. Of course, I might be wrong.
I guess you're wrong :-) That's the purpose of branches. To work on a task
isolated from each other. If you're done with it, the branch is merged to a
relase branch. If it's not needed anymore it's either ignored, or can be
deleted completely. And no, nobody cares about the number of branch types
created in any particular VOB.
> | What I do at home is usually totally unrelated to my work, so I don't
> | care.
> OK, but you can understand that for me it's a useful property I do care
> about, right?
Yes, sure.
Bye...
Dirk
tatyana
> tatyana wrote:
>> For example, functionality to analyze hundreds of config record
>> hierarchies for the purposes other than winking, e.g. for comparing
>> two different tests.
> ct catcr -r my_top_level_do >~/cr_<view_tag>
In the example above you assume, I guess, that the test explicitly
executes (or is itself) the top-level DO of the clearmake-performed
build.
First, that is a very particular case. Generally speaking, one
wouldn't necessarily know what is the top-level target, is it the only
one or how many of them there are, etc. Consider e.g. something like
"perl test" as a test.
Second, some other DOs may be involved during the test run, rather
than those that were used during the build: e.g. in case of system()
calls, etc.
Third, even considering the assumption above, i.e. comparing the two
built targets (not the tests!) that are restricted to be makefile-
based only and made with clearmake (OK, also Ant+clearaudit in
ClearCase 7), wouldn't succeed:
- "ct catcr -r" doesn't handle DO hierarchies properly: it doesn't
examine all the sub-DOs. So, one would need to write an own proper
recursive analyzer.
- The output of the catcr flattens the two different config records in
scattered order, so one would need to assemble them back and compare
the actual cr objects/structures.
And this is, in fact, something one would like to ask from ClearCase:
please, compare the actual cr objects for all the relevant DOs
involved during my tests run.
> ct catcr `find . <all my DOs>` >~/cr_<view_tag>
It's not relevant, I think, as first, one doesn't need all the DOs,
but only the relevant ones; and second, it's actually the DOs
hierarchies, that need to be analyzed.
Tanya.
Andrew DeFaria
On Apr 20, 7:18 pm, Dirk Heinrichs <dirk.heinri...@online.de> wrote:
tatyana wrote:
For example, functionality to analyze hundreds of config record hierarchies for the purposes other than winking, e.g. for comparing two different tests.
ct catcr -r my_top_level_do >~/cr_<view_tag>In the example above you assume, I guess, that the test explicitly executes (or is itself) the top-level DO of the clearmake-performed build.
First, that is a very particular case. Generally speaking, one wouldn't necessarily know what is the top-level target, is it the only one or how many of them there are, etc. Consider e.g. something like "perl test" as a test.
Second, some other DOs may be involved during the test run, rather than those that were used during the build: e.g. in case of system() calls, etc.
Third, even considering the assumption above, i.e. comparing the two built targets (not the tests!) that are restricted to be makefile- based only and made with clearmake (OK, also Ant+clearaudit in ClearCase 7), wouldn't succeed:
- "ct catcr -r" doesn't handle DO hierarchies properly: it doesn't examine all the sub-DOs. So, one would need to write an own proper recursive analyzer.
- The output of the catcr flattens the two different config records in scattered order, so one would need to assemble them back and compare the actual cr objects/structures.
And this is, in fact, something one would like to ask from ClearCase: please, compare the actual cr objects for all the relevant DOs involved during my tests run.
ct catcr `find . <all my DOs>` >~/cr_<view_tag>It's not relevant, I think, as first, one doesn't need all the DOs, but only the relevant ones; and second, it's actually the DOs
hierarchies, that need to be analyzed.
Andrew DeFaria
Andrew DeFaria
Going to church does not make you a Christian any more than standing in a garage makes you a car.
Dirk Heinrichs
> On Apr 20, 7:18 pm, Dirk Heinrichs <dirk.heinri...@online.de> wrote:
>> tatyana wrote:
>>> For example, functionality to analyze hundreds of config record
>>> hierarchies for the purposes other than winking, e.g. for comparing
>>> two different tests.
>
>> ct catcr -r my_top_level_do >~/cr_<view_tag>
>
> In the example above you assume, I guess, that the test explicitly
> executes (or is itself) the top-level DO of the clearmake-performed
> build.
I assume nothing. That's just what you said: examples. I don't know your
working environment, it's up to you adapt them to your needs.
> - "ct catcr -r" doesn't handle DO hierarchies properly: it doesn't
> examine all the sub-DOs. So, one would need to write an own proper
> recursive analyzer.
??? Of course it does.
> - The output of the catcr flattens the two different config records in
> scattered order, so one would need to assemble them back and compare
> the actual cr objects/structures.
Then make sure the order is always the same. There's tools out there to do
this for you, namely find and sort, see the second example.
> And this is, in fact, something one would like to ask from ClearCase:
> please, compare the actual cr objects for all the relevant DOs
> involved during my tests run.
Again, all you need is there.
>> ct catcr `find . <all my DOs>` >~/cr_<view_tag>
>
> It's not relevant, I think, as first, one doesn't need all the DOs,
> but only the relevant ones; and second, it's actually the DOs
> hierarchies, that need to be analyzed.
That's just another example.
I'm sure I could find one that that fits your need, but I leave this
exercise to you ;-)
Bye...
Dirk
Marc Girod
> For example, functionality to analyze hundreds of config record
> hierarchies for the purposes other than winking, e.g. for comparing
> two different tests.
Indeed. I find it is amazing that ClearCase has so
steadily ignored this obvious and natural development
direction.
Nothing had been done to narrow the differences
between incompatible configurations, this despite
the fact that there were several independent
contributions in this respect (I remember once again
David Boyce's offering).
But you are right: this is only an example. I would
also think of /lazy/ identification of DOs produced
with accidentally differing dependency trees (the
obvious case being javac files produced on different
platforms, thus with different implementations of the
same compiler). Such grouping of DO families into
equivalence classes, would have been one way to
solve this oldest recorded RFE (the Doug Robinson
RFE: shopping for DOs, and having found two
identical ones, one would pick the older of the two,
instead of the newer as was done inadvertently);
fixing this obvious error has been promised for
almost 15 years, and always postponed as
requiring a change of the database schema.
Marc