Tags & production questions

[Guido Ostkamp]

On Fri, 4 May 2007, Mark A. Flacy wrote:

> Do you use straight ClearCase or do you use UCM?

As I have never heard about 'UCM', I would say we use pure ClearCase.

> In the "real" world (where ever that may be), you'd have several files 
> in a changeset since you would desire that they all are committed to the 
> repository as a unit.  (In ClearCase/UCM terminology, that would be an 
> "activity". There, an "activity" can contain multiple versions of 
> multiple files.)

I am not sure what you mean with "multiple versions of multiple files". 
Do you mean you check in not only a collection of different files at once, 
but also numerous such collections (probably designed for different 
branches) at once?

I think the general concept of versioning the whole repository at once 
(and not by file) and thus allowing to check in multiple files at once, is 
the same in SVN, git and Mercurial.

However, I am not sure how well this works in real life. For example one 
developer checks in n-1 files but has forgotten one. He probably isn't 
able to rollback his work because somebody else has done another commit 
before he detected the problem. In this case you don't have an atomic 
changeset. To fix this, the developer would have to undo changes of other 
persons and his own and to replay them in corrected fashion. This would 
certainly leave some chaos in the logs.

>>  Typically, each developer has a quota of just a few Gigabytes, let say 
>> 5 GB, which he cannot exceed.
>
> Wow, they are pretty generous.  Our limit is 500MB on the Unix servers. 
> Designer desktops are 80GB (assuming that you don't just go out and buy 
> another disk drive yourself).
> [...]  But we're able to compile on our desktops, which I guess
> you cannot.

You are correct, due to policy defined by the Chief Information Officer in 
our company, we all are forced to use Windows XP desktops that are more or 
less centrally remote administered. We neither get BIOS nor Admin 
passwords and only selected software can be installed. There is no chance 
to use it for any compilation of our real work.

Regarding the space, the numbers I mentioned were without compilation, 
linking and packaging results. If you add the missing stuff, then even 
with ClearCase views where the sources don't eat up space, the rest 
quickly uses up the quota. Typically you cannot deal with more than 3 
built views at one time which is already too less.

>> Thus it is absolutely crucial to have everything available in 
>> onerepository. It would be an absolute nightmare to have each of 
>> themaintenance releases of each branch in its own repository.
>
> Well, no, it wouldn't be.  You can merge across repositories with ease 
> with Mercurial, which you cannot do with ClearCase.  The main point, 
> though, is that you've *got* to start thinking in terms of changesets 
> rather than in terms of individual file versions when you work with 
> Mercurial.  One of your changesets would *be* the bug fix and *that* is 
> what you would share across the repositories.

I still need to find out which fixes have been ported to which branches. 
With cloned repositories I would have to jump between different pathes of 
the repositories all the time and then extract file versions, diff them or 
call the repository logs. Having it all in one repository is easier (my 
personal opinion).

> Right now, you're probably running findmerge or something similar.

Unfortunately, at present this is more or less a completely manual action.

> I think that ClearCase/UCM would be an improvement over your current 
> setup.

Possibly. But as I said, I have to live with what is available. I can only 
try to optimize my work by using additional free tools like Mercurial and 
of course learn about such tools for future projects.

> Well, there's going to be a methodology mismatch.  That might get in the 
> way of what you're trying to do.

If there is no way to accurately model ClearCase branches in Mercurial 
where each file can have optionally been branched from any version, then I 
can only try to emulate the stuff by creating a seperate repository which 
is build from the ground up, but does not contain any Mercurial branches.

Regarding tags we have already discussed that, but it will become ugly.

I have still the option to give up on this and use Mercurial or git only 
as interim solution for improvement of small components inside the 
ClearCase view.

Regards

Guido