Système de Gestion de Versions: Logiciel de Gestion de Versions, Bitkeeper, Clearcase, Revision Control System, Pvcs, Gforge, Fusionforge (French Edition)

Les achats comprennent une adhésion à l'essai gratuite au club de livres de l'éditeur, dans lequel vous pouvez choisir parmi plus d'un million d'ouvrages, sans frais. Le livre consiste d'articles Wikipedia sur : Logiciel de Gestion de Versions, Bitkeeper, Clearcase, Revision Control System, Pvcs, Gforge, Fusionforge, Savane, Perforce, Microsoft Visual Sourcesafe, Synergy, Visualsvn, Tailor, Label, Gestion Concurrente de Versions, Smartsvn. Non illustré. Mises à jour gratuites en ligne. Extrait : La gestion de versions (en anglais ou ) est une activité qui consiste à maintenir l'ensemble des versions ou révisions d'un logiciel ou autre document. Essentiellement utilisée dans le domaine de la création de logiciels, elle est surtout concernée par le code source ; mais elle peut être utilisée pour tout type de document informatique. Cette activité étant fastidieuse et relativement complexe, un appui logiciel est presque indispensable. À cet effet, il existe différents logiciels de gestion de versions qui, bien qu'ayant des concepts essentiels communs, apportent chacun son propre vocabulaire et ses propres usages. À titre d'exemple, on trouve un mécanisme de gestion de versions dans Wikipédia : pour chaque article, l'historique est disponible en cliquant sur le lien Historique. Les logiciels évoluant, chaque étape d'avancement est appelée version. Les différentes versions sont nécessairement liées à travers des modifications. Une modification peut correspondre à des ajouts, modifications, suppressions ou une combinaison des trois sur une version donnée. Schématiquement, on passera de la version N à la version N + 1 en appliquant une modification M. Un logiciel de gestion de versions nous aidera alors à soustraire la modification M de la version N + 1 pour retrouver la version N. Les concepteurs du logiciel de gestion de versions RCS ont choisi de parler de « révisions » (revisions) afin de ne pas confondre la version du logiciel a...http://booksllc.net/?l=fr

Price: $19.99

Click here to buy from Amazon

Subject: Cruise Control Integration with ClearCase - by: martina

Hi Martina,

Thanks for your responce. I want to update my view when I trigger the build using Cruise control. Do you know the clear case plugins to do that and how to use them?

Thanks,
Scott

View the original article here

Subject: Cruise Control Integration with ClearCase - by: scott123

Hi Martina,

Thanks for your responce. I want to update my view when I trigger the build using Cruise control. Do you know the clear case plugins to do that and how to use them?

Thanks,
Scott

View the original article here

Subject: Cruise Control Integration with ClearCase - by: martina

Welcome, Guest
Please Login or Register.    Lost Password? Sorry, I could not read the content fromt this page.

View the original article here

Subject: Event 2010-10-25: Distributed Version Control - by: vinnyjames

@vinnyjames
I think you assumed I meant 'DVCS like local copies of the repository history' when what I actually wrote was 'local history---a little like DVCS'. I confess that the added 'a little like DVCS' could be misinterpreted. There have been plenty of announcements about Subversion 1.7 changes to the working copy...

Like this.

Looks very much like an announcement on the Subversion Community site (which is sponsored by your organisation isn't it?) that the Subversion 1.7 will have...
Next Generation Working Copy (WC-NG), enhancing the existing working copy functionality with centralised metadata storage and improved extensibility. This will provide the groundwork to allow offline commits and other features associated with Distributed Version Control Systems (DVCS) such as Git and Mercurial.

Oh, and here's the original press release from WANDisco.

While details are a bit sketchy, "offline commits" and " other features associated with Distributed Version Control Systems", to me, implied maintaining at least a simple working copy history. What use would an "offline commit" be if it did not maintain a local history of these "offline commits"? I think that, in light of this announcement, my observation that there were moves to make '... Subversion working copies maintain local history---a little like DVCS' was not unreasonable.

And this presentation (pages 12-16) in which the idea of "shelving" ("Offline commits") is once again mentioned.

And this article (scroll down to section 2 "SVN vs. GIT, Mercurial and Bazaar", which again mentions shelving and "distributed VCS storage".

There's plenty more, just Google "Subversion 1.7". As I said, I may have misinterpreted what "offline commit" means, but if it does not mean some sort of locally maintained history what use is it?

As for the rest, it was not my intention to start a long debate about the relative merits of DVCS versus central server VCS. I am more than happy to have that debate and I see much merit in both models. I would suggest however that we take any future debate over to the General forum where it will enjoy a larger audience and more participants.

Briefly, to your point about a full history being more useful to a miscreant than a 'sandbox' because they could (with sufficient patience and skill) divine management intentions etc. from such a repository. What you say is true of course, but any machine that exposed such a repository would probably contain information of that sort in a much more readily accessible form (emails, developer notes, meeting minutes, documentation, models, plans, etc.) Any organisation concerned in the slightest about laptop security uses low level encryption systems like SafeBoot (I think it's now called McAfee Endpoint Encryption) to protect the whole asset, so the concerns about information falling into the wrong hands are moot aren't they? This whole "you have your entire product history on the laptop" is a bit of a red herring. Security should be much better than relying on the fact your developers are only carrying around part of your code's history.

Besides (while we're conjuring bogey men), in most organisations where I've used Subversion the developers cache their username/passwords. If we're dreaming up a bad-guy smart enough to divine management intentions from a code base, then I suggest he's also smart enough to not even bother stealing the laptop, he just copies the user's cached credentials and then merrily surfs around the central repository. (And yes, there are plenty of ways to protect against this risk, but then we were positing an organisation so dumb they would not encrypt laptops holding their code base and other IP.)

I never said 'DVCS isn't stored in silos', I said 'It is equally silly, hysterical, and ill-informed to say DVCS are "disparate silos of data..." stored on "laptops and ad-hoc servers"'. I was making an observation about the tone of the message, not the fact of it (although I do challenge the implications of what you wrote).

My original point was not to favour one solution over the other (I really don't, I like to understand the problem to be solved before deciding on the solution), but to point out that a blanket statement that "solution X" is right and "solution Y" is wrong without knowing the specifics of a situation was rather silly.

Okay, if you're interested in a debate about the relative merits of different approaches to version control, then please address it on the General Forum where I'll be happy to engage (and I am certain you will get many more different, interesting, and heated, views on the topic from the very smart and well informed CM practitioners who hang out there).

View the original article here

Subject: Event 2010-10-25: Distributed Version Control - by: mbools

@vinnyjames
I think you assumed I meant 'DVCS like local copies of the repository history' when what I actually wrote was 'local history---a little like DVCS'. I confess that the added 'a little like DVCS' could be misinterpreted. There have been plenty of announcements about Subversion 1.7 changes to the working copy...

Like this.

Looks very much like an announcement on the Subversion Community site (which is sponsored by your organisation isn't it?) that the Subversion 1.7 will have...
Next Generation Working Copy (WC-NG), enhancing the existing working copy functionality with centralised metadata storage and improved extensibility. This will provide the groundwork to allow offline commits and other features associated with Distributed Version Control Systems (DVCS) such as Git and Mercurial.

Oh, and here's the original press release from WANDisco.

While details are a bit sketchy, "offline commits" and " other features associated with Distributed Version Control Systems", to me, implied maintaining at least a simple working copy history. What use would an "offline commit" be if it did not maintain a local history of these "offline commits"? I think that, in light of this announcement, my observation that there were moves to make '... Subversion working copies maintain local history---a little like DVCS' was not unreasonable.

And this presentation (pages 12-16) in which the idea of "shelving" ("Offline commits") is once again mentioned.

And this article (scroll down to section 2 "SVN vs. GIT, Mercurial and Bazaar", which again mentions shelving and "distributed VCS storage".

There's plenty more, just Google "Subversion 1.7". As I said, I may have misinterpreted what "offline commit" means, but if it does not mean some sort of locally maintained history what use is it?

As for the rest, it was not my intention to start a long debate about the relative merits of DVCS versus central server VCS. I am more than happy to have that debate and I see much merit in both models. I would suggest however that we take any future debate over to the General forum where it will enjoy a larger audience and more participants.

Briefly, to your point about a full history being more useful to a miscreant than a 'sandbox' because they could (with sufficient patience and skill) divine management intentions etc. from such a repository. What you say is true of course, but any machine that exposed such a repository would probably contain information of that sort in a much more readily accessible form (emails, developer notes, meeting minutes, documentation, models, plans, etc.) Any organisation concerned in the slightest about laptop security uses low level encryption systems like SafeBoot (I think it's now called McAfee Endpoint Encryption) to protect the whole asset, so the concerns about information falling into the wrong hands are moot aren't they? This whole "you have your entire product history on the laptop" is a bit of a red herring. Security should be much better than relying on the fact your developers are only carrying around part of your code's history.

Besides (while we're conjuring bogey men), in most organisations where I've used Subversion the developers cache their username/passwords. If we're dreaming up a bad-guy smart enough to divine management intentions from a code base, then I suggest he's also smart enough to not even bother stealing the laptop, he just copies the user's cached credentials and then merrily surfs around the central repository. (And yes, there are plenty of ways to protect against this risk, but then we were positing an organisation so dumb they would not encrypt laptops holding their code base and other IP.)

I never said 'DVCS isn't stored in silos', I said 'It is equally silly, hysterical, and ill-informed to say DVCS are "disparate silos of data..." stored on "laptops and ad-hoc servers"'. I was making an observation about the tone of the message, not the fact of it (although I do challenge the implications of what you wrote).

My original point was not to favour one solution over the other (I really don't, I like to understand the problem to be solved before deciding on the solution), but to point out that a blanket statement that "solution X" is right and "solution Y" is wrong without knowing the specifics of a situation was rather silly.

Okay, if you're interested in a debate about the relative merits of different approaches to version control, then please address it on the General Forum where I'll be happy to engage (and I am certain you will get many more different, interesting, and heated, views on the topic from the very smart and well informed CM practitioners who hang out there).

View the original article here

Subject: Event 2010-10-25: Distributed Version Control - by: vinnyjames

Presented by Dan North, Agile troublemaker, developer and originator of BDD

This is a joint event with the BCS Open Source SG.

Synopsis
Big organisations like to centralise. They like the control and management of centralised services. Distributed source code management (DSCM) systems such as git and mercurial represent a potentially disruptive shift in version control. Dan has been using DSCMs for his personal projects for a couple of years now, and recently his company - a 500 person trading firm - took the decision to embrace DSCM and begin the migration towards git from its centralised, monolithic Subversion repository.

In this talk, Dan outlines some of the differences between centralised and distributed version control systems, from a technical, social and organisational perspective, and describes some of the challenges of migrating towards and using DSCM successfully in a commercial setting.

www.bcs-cmsg.org.uk/events/2010-11-25.html

View the original article here

Subject: Event 2010-10-25: Distributed Version Control - by: robertc

@vinnyjames I realise you're just promoting your product, but absolutist statements like your's are plainly wrong and do not reflect well on your organisation. You cannot know what is right for all organisations. Making these statements makes you look like a one trick pony--"The answer is Subversion MultiSite. Now, what was the question?".

The synopsis does not call Subversion 'monolithic' it say's Dan's organisation's Subversion repository was centralised and monolithic, which it may well have been. I think he's better placed to make that observation than you.

It is equally silly, hysterical, and ill-informed to say DVCS are "disparate silos of data..." stored on "laptops and ad-hoc servers". It really depends on how you manage your system.

Oh, and a company's IP is all over laptops etc. with Subversion (or don't you allow working copies on laptops?). (And I assume that you're aware of the moves to make Subversion working copies maintain local history---a little like DVCS?)

If you're going to plug your product on unrelated threads (this was an event announcement, not an advocacy piece), at least do it in a way that reflects well on you, it, and your organisation.

View the original article here

Subject: Event 2010-10-25: Distributed Version Control - by: robertc

Presented by Dan North, Agile troublemaker, developer and originator of BDD

This is a joint event with the BCS Open Source SG.

Synopsis
Big organisations like to centralise. They like the control and management of centralised services. Distributed source code management (DSCM) systems such as git and mercurial represent a potentially disruptive shift in version control. Dan has been using DSCMs for his personal projects for a couple of years now, and recently his company - a 500 person trading firm - took the decision to embrace DSCM and begin the migration towards git from its centralised, monolithic Subversion repository.

In this talk, Dan outlines some of the differences between centralised and distributed version control systems, from a technical, social and organisational perspective, and describes some of the challenges of migrating towards and using DSCM successfully in a commercial setting.

www.bcs-cmsg.org.uk/events/2010-11-25.html

View the original article here

Re: VOB access control

This question is not answered.

Posts: 13
Registered: Feb 05, 2010 07:44:50 AM VOB access control
Posted: Oct 29, 2010 10:54:29 AM Hi,

I am trying to understand a bit to Clearcase access control to VOBs. Basically, my point would be to do so that not every user of the Clearcase server is able to see every VOBs in it.

I am having a test "server" on a XP machine and am connecting to it with another PC. Now that I've spent my whole day on this subject, I am asking myself whether the "cleartool protectvob -add_group..." function is really useful; explanations:

As far as I understood, Clearcase access control is based on windows access control (right click on a vob folder, security and share...)When I add a group through cleartool to the vob, I don't see any change in the windows security window.When I 'cleartool describe' a vob folder, I only get "User : UNKNOWN and Group: UNKNOWN" informationThe only achievements to which I got today were by changing directly the accesses to the ".vbs" folders either for the PVOB or the VOB, without passing by cleartool.
Is there anything I am missing (since I didn't really get far on this subject yet), which would require the use of protectvob etc.? What is in your opinion the best way to get a good control on the visibility to the VOB for the different users?

Many thanks to whoever would answer my questions :)

Posts: 417
Registered: Sep 28, 2005 02:20:11 PM Re: VOB access control
Posted: Oct 29, 2010 11:24:29 AM   in response to: PResin's post >> * As far as I understood, Clearcase access control is based on windows access control (right click on a vob folder, security and share...)

Yes and no. Windows access control is only part of the picture. Windows access control it what gets you to the containers in the pools, and what limits your ability to mount a VOB. Beyond that, you're looking strictly at ClearCase permissions, which are more unix-like.

>> * When I add a group through cleartool to the vob, I don't see any change in the windows security window.

Generally speaking, this is normal behavior. You may see the windows permissions on the pool directories change, but not on the .vbs itself. cleartool protect -add_group adds a group to the list of groups that can create or "own" elements within the VOB. That's essentially ALL it does. It does not control a user's ability to access elements in that VOB. The element permissions do that.

>> * When I 'cleartool describe' a vob folder, I only get "User : UNKNOWN and Group: UNKNOWN" information

This shouldn't happen unless the user who owns that element can't be looked up from the host you're on. Are you using a non-domain system as the test system?

>> * The only achievements to which I got today were by changing directly the accesses to the ".vbs" folders either for the PVOB or the VOB, without passing by cleartool.

Don't do this. You run a better than 90% chance of BREAKING the VOB storage directory permissions. You will become very familiar with the "fix_prot" utility if you persist in doing this.

If this is an all-Windows environment, and you want only authorized users to be able to mount VOBs (If users can't mount the VOB, they can't access the contents) try setting up multiple project-specific shares on your VOB server. You then grant ONLY the "ClearCase Server process Group" and the group of users access through that share using SHARE PERMISSIONS ONLY. You may have users who try to get around this using snapshot views, but while they may be able to see the NAMES of the files in the directories, they won't be able to load any of those files into their views. If you want to limit that, you would have to work with element permissions. The biggest problem here is that you can only work with 16 or 32 groups, depending on the VOB storage platform, and this limits the number of options you have there.

=================================================================
Brian Cowan
Advisory Software Engineer
ClearCase SoftWare Advisory Team (SWAT)
Rational Software
IBM Software Group
550 King St
Littleton, MA 01460

Phone: 1.978.899.9471
Web: http://www.ibm.com/software/rational/support/

Posts: 13
Registered: Feb 05, 2010 07:44:50 AM Re: VOB access control
Posted: Nov 01, 2010 05:58:34 AM   in response to: brcowan's post Thank you Brian for your answer.

I should have maybe mentioned that I'm still a beginner in Clearcase management, thus the following answers may reflect my level.

%% >> * As far as I understood, Clearcase access control is based on windows access control (right click on a vob folder, security and share...)

%% Yes and no. Windows access control is only part of the picture. Windows access control it what gets you to the containers in the pools, and what limits your ability to mount a VOB. Beyond that, you're looking strictly at ClearCase permissions, which are more unix-like.

%% >> * When I add a group through cleartool to the vob, I don't see any change in the windows security window.

%% Generally speaking, this is normal behavior. You may see the windows permissions on the pool directories change, but not on the .vbs itself. cleartool protect -add_group adds a group to the list of groups that can create or "own" elements within the VOB. That's essentially ALL it does. It does not control a user's ability to access elements in that VOB. The element permissions do that.

Ok, that's understood :)

%% >> * When I 'cleartool describe' a vob folder, I only get "User : UNKNOWN and Group: UNKNOWN" information

%% This shouldn't happen unless the user who owns that element can't be looked up from the host you're on. Are you using a non-domain system as the test system?

I am using a computer in the domain and everything; this may be due the different manipulations I did on the VOBs. Once I get the clean method to protect vobs, I will create new test VOBs and see if this problem remains.

%% >> * The only achievements to which I got today were by changing directly the accesses to the ".vbs" folders either for the PVOB or the VOB, without passing by cleartool.

%% Don't do this. You run a better than 90% chance of BREAKING the VOB storage directory permissions. You will become very familiar with the "fix_prot" utility if you persist in doing this.

Good to know. I actually got this kind of errors, and trying fix_prot returned me errors in the permissions messsage.

----

Now the hardest part for me.

%% If this is an all-Windows environment (yes), and you want only authorized users to be able to mount VOBs
I may not have used the correct method previously but so far what I'm doing is using the project explorer to display the different VOBs (from which I can already see the different activities that I would like to hide) and I never "mounted" a VOB, am I doing all wrong?

%%(If users can't mount the VOB, they can't access the contents) try setting up multiple project-specific shares on your VOB server.
"Multiple project specific shares". On my side I am creating One set of VOB/PVOB per project. Then creating "clearcase-named" projects per sub-project (Aouch...this isn't clear..let's say that I have one project to develop an airplane software and another one to develop a pong game, these would be two different VOBS, then if I have two sub-projects within the airplane software project, there I would create two clearcase projects within the VOB), is it the right way to do it?

%% You then grant ONLY the "ClearCase Server process Group" and the group of users access through that share using SHARE PERMISSIONS ONLY.
Are you here mentioning the SHARE PERMISSIONS on the windows environment or another way to handle it? Supposing I have a base cleacase group ccgroup and two other groups that shouldn't have access to every VOB (+ccgp1+ & +ccgp2+), shall I only give SHARE PERMISSIONS to ccgroup and not the others in other to avoid having them seeing the VOB? IS it really sufficient?

%% You may have users who try to get around this using snapshot views, but while they may be able to see the NAMES of the files in the directories, they won't be able to load any of those files into their views.
If they can create views then I suppose that they can see the activites?

%% If you want to limit that, you would have to work with element permissions. The biggest problem here is that you can only work with 16 or 32 groups, depending on the VOB storage platform, and this limits the number of options you have there.

Sorry for all these questions but I feel like I always did the wrong way since I discovered Clearcase...

Posts: 13
Registered: Feb 05, 2010 07:44:50 AM Re: VOB access control
Posted: Nov 02, 2010 03:40:40 AM   in response to: PResin's post Hi again,

I guess by the number of views and the lack of answers that my reply was a bit long, thus discouraging...let's make it shorter:

Why do we have to mount a VOB? On my side, I am seeing them in the project explorer without mounting them.
Are the SHARE PERMISSIONS the ones handled with Windows or is there another way?
My goal is, having a PVOB and a VOB, to hide even the activities for the streams etc. is it feasible?
Hoping that this simplifies the reading, the answers may be a good start for me.

Thanks to anybody who could answer this!

Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

Popular tags shows the top tags for this particular type of content or application that you're viewing.

My tags shows your tags for this particular type of content or application that you're viewing.

Use the search field to find all types of content in My developerWorks with that tag. Use the slider bar to see more or fewer tags. Popular tags shows the top tags for this particular type of content or application that you're viewing. My tags shows your tags for this particular type of content or application that you're viewing.MoreLess 

View the original article here

Re: VOB access control

This question is not answered.

Posts: 14
Registered: Feb 05, 2010 07:44:50 AM VOB access control
Posted: Oct 29, 2010 10:54:29 AM Hi,

I am trying to understand a bit to Clearcase access control to VOBs. Basically, my point would be to do so that not every user of the Clearcase server is able to see every VOBs in it.

I am having a test "server" on a XP machine and am connecting to it with another PC. Now that I've spent my whole day on this subject, I am asking myself whether the "cleartool protectvob -add_group..." function is really useful; explanations:

As far as I understood, Clearcase access control is based on windows access control (right click on a vob folder, security and share...)When I add a group through cleartool to the vob, I don't see any change in the windows security window.When I 'cleartool describe' a vob folder, I only get "User : UNKNOWN and Group: UNKNOWN" informationThe only achievements to which I got today were by changing directly the accesses to the ".vbs" folders either for the PVOB or the VOB, without passing by cleartool.
Is there anything I am missing (since I didn't really get far on this subject yet), which would require the use of protectvob etc.? What is in your opinion the best way to get a good control on the visibility to the VOB for the different users?

Many thanks to whoever would answer my questions :)

Posts: 417
Registered: Sep 28, 2005 02:20:11 PM Re: VOB access control
Posted: Oct 29, 2010 11:24:29 AM   in response to: PResin's post >> * As far as I understood, Clearcase access control is based on windows access control (right click on a vob folder, security and share...)

Yes and no. Windows access control is only part of the picture. Windows access control it what gets you to the containers in the pools, and what limits your ability to mount a VOB. Beyond that, you're looking strictly at ClearCase permissions, which are more unix-like.

>> * When I add a group through cleartool to the vob, I don't see any change in the windows security window.

Generally speaking, this is normal behavior. You may see the windows permissions on the pool directories change, but not on the .vbs itself. cleartool protect -add_group adds a group to the list of groups that can create or "own" elements within the VOB. That's essentially ALL it does. It does not control a user's ability to access elements in that VOB. The element permissions do that.

>> * When I 'cleartool describe' a vob folder, I only get "User : UNKNOWN and Group: UNKNOWN" information

This shouldn't happen unless the user who owns that element can't be looked up from the host you're on. Are you using a non-domain system as the test system?

>> * The only achievements to which I got today were by changing directly the accesses to the ".vbs" folders either for the PVOB or the VOB, without passing by cleartool.

Don't do this. You run a better than 90% chance of BREAKING the VOB storage directory permissions. You will become very familiar with the "fix_prot" utility if you persist in doing this.

If this is an all-Windows environment, and you want only authorized users to be able to mount VOBs (If users can't mount the VOB, they can't access the contents) try setting up multiple project-specific shares on your VOB server. You then grant ONLY the "ClearCase Server process Group" and the group of users access through that share using SHARE PERMISSIONS ONLY. You may have users who try to get around this using snapshot views, but while they may be able to see the NAMES of the files in the directories, they won't be able to load any of those files into their views. If you want to limit that, you would have to work with element permissions. The biggest problem here is that you can only work with 16 or 32 groups, depending on the VOB storage platform, and this limits the number of options you have there.

=================================================================
Brian Cowan
Advisory Software Engineer
ClearCase SoftWare Advisory Team (SWAT)
Rational Software
IBM Software Group
550 King St
Littleton, MA 01460

Phone: 1.978.899.9471
Web: http://www.ibm.com/software/rational/support/

Posts: 14
Registered: Feb 05, 2010 07:44:50 AM Re: VOB access control
Posted: Nov 01, 2010 05:58:34 AM   in response to: brcowan's post Thank you Brian for your answer.

I should have maybe mentioned that I'm still a beginner in Clearcase management, thus the following answers may reflect my level.

%% >> * As far as I understood, Clearcase access control is based on windows access control (right click on a vob folder, security and share...)

%% Yes and no. Windows access control is only part of the picture. Windows access control it what gets you to the containers in the pools, and what limits your ability to mount a VOB. Beyond that, you're looking strictly at ClearCase permissions, which are more unix-like.

%% >> * When I add a group through cleartool to the vob, I don't see any change in the windows security window.

%% Generally speaking, this is normal behavior. You may see the windows permissions on the pool directories change, but not on the .vbs itself. cleartool protect -add_group adds a group to the list of groups that can create or "own" elements within the VOB. That's essentially ALL it does. It does not control a user's ability to access elements in that VOB. The element permissions do that.

Ok, that's understood :)

%% >> * When I 'cleartool describe' a vob folder, I only get "User : UNKNOWN and Group: UNKNOWN" information

%% This shouldn't happen unless the user who owns that element can't be looked up from the host you're on. Are you using a non-domain system as the test system?

I am using a computer in the domain and everything; this may be due the different manipulations I did on the VOBs. Once I get the clean method to protect vobs, I will create new test VOBs and see if this problem remains.

%% >> * The only achievements to which I got today were by changing directly the accesses to the ".vbs" folders either for the PVOB or the VOB, without passing by cleartool.

%% Don't do this. You run a better than 90% chance of BREAKING the VOB storage directory permissions. You will become very familiar with the "fix_prot" utility if you persist in doing this.

Good to know. I actually got this kind of errors, and trying fix_prot returned me errors in the permissions messsage.

----

Now the hardest part for me.

%% If this is an all-Windows environment (yes), and you want only authorized users to be able to mount VOBs
I may not have used the correct method previously but so far what I'm doing is using the project explorer to display the different VOBs (from which I can already see the different activities that I would like to hide) and I never "mounted" a VOB, am I doing all wrong?

%%(If users can't mount the VOB, they can't access the contents) try setting up multiple project-specific shares on your VOB server.
"Multiple project specific shares". On my side I am creating One set of VOB/PVOB per project. Then creating "clearcase-named" projects per sub-project (Aouch...this isn't clear..let's say that I have one project to develop an airplane software and another one to develop a pong game, these would be two different VOBS, then if I have two sub-projects within the airplane software project, there I would create two clearcase projects within the VOB), is it the right way to do it?

%% You then grant ONLY the "ClearCase Server process Group" and the group of users access through that share using SHARE PERMISSIONS ONLY.
Are you here mentioning the SHARE PERMISSIONS on the windows environment or another way to handle it? Supposing I have a base cleacase group ccgroup and two other groups that shouldn't have access to every VOB (+ccgp1+ & +ccgp2+), shall I only give SHARE PERMISSIONS to ccgroup and not the others in other to avoid having them seeing the VOB? IS it really sufficient?

%% You may have users who try to get around this using snapshot views, but while they may be able to see the NAMES of the files in the directories, they won't be able to load any of those files into their views.
If they can create views then I suppose that they can see the activites?

%% If you want to limit that, you would have to work with element permissions. The biggest problem here is that you can only work with 16 or 32 groups, depending on the VOB storage platform, and this limits the number of options you have there.

Sorry for all these questions but I feel like I always did the wrong way since I discovered Clearcase...

Posts: 14
Registered: Feb 05, 2010 07:44:50 AM Re: VOB access control
Posted: Nov 02, 2010 03:40:40 AM   in response to: PResin's post Hi again,

I guess by the number of views and the lack of answers that my reply was a bit long, thus discouraging...let's make it shorter:

Why do we have to mount a VOB? On my side, I am seeing them in the project explorer without mounting them.
Are the SHARE PERMISSIONS the ones handled with Windows or is there another way?
My goal is, having a PVOB and a VOB, to hide even the activities for the streams etc. is it feasible?
Hoping that this simplifies the reading, the answers may be a good start for me.

Thanks to anybody who could answer this!

Posts: 14
Registered: Feb 05, 2010 07:44:50 AM Re: VOB access control
Posted: Nov 03, 2010 05:18:44 AM   in response to: PResin's post It seems like nobody really has answers for me; anyway here are some updates on what I've found: On PVOB folder, when removing NTFS security "write" permission to the primary group, then the user can not see the PVOB in the project explorer anymore.
Om VOB folder, when removing NTFS security"write" permission to the primary group, then the user can not see the VOB components when creating a view on a stream.
It seems that the more restrictive access security apply, therefore creating NTFS security rights for a specific user (myself in my case) doesn't have any effect.
Given that I don't know much about windows security, I've found this article: http://www.windowsecurity.com/articles/Share-Permissions.html, that states that "when the NTFS permissions are combined with the share permissions, the most secure of the two permissions controls the access to the resource.". In my case, I've tried to apply restrictive share permissions, as recommended by Brian, but it had absolutely no effect.
Again, my questions may be due to the fact that I am testing the Clearcase server on a WinXP machine and not on a real server, but if anybody has more information or tutorials on how to control the access and visibility for different users on Clearcase, please answer this thread, as for the moment, I feel kind of lost in it :).

Thanks in advance...please... :)

Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

Popular tags shows the top tags for this particular type of content or application that you're viewing.

My tags shows your tags for this particular type of content or application that you're viewing.

Use the search field to find all types of content in My developerWorks with that tag. Use the slider bar to see more or fewer tags. Popular tags shows the top tags for this particular type of content or application that you're viewing. My tags shows your tags for this particular type of content or application that you're viewing.MoreLess 

View the original article here

Re: VOB access control

Thank you Brian for your answer.

I should have maybe mentioned that I'm still a beginner in Clearcase management, thus the following answers may reflect my level.

%% >> * As far as I understood, Clearcase access control is based on windows access control (right click on a vob folder, security and share...)

%% Yes and no. Windows access control is only part of the picture. Windows access control it what gets you to the containers in the pools, and what limits your ability to mount a VOB. Beyond that, you're looking strictly at ClearCase permissions, which are more unix-like.

%% >> * When I add a group through cleartool to the vob, I don't see any change in the windows security window.

%% Generally speaking, this is normal behavior. You may see the windows permissions on the pool directories change, but not on the .vbs itself. cleartool protect -add_group adds a group to the list of groups that can create or "own" elements within the VOB. That's essentially ALL it does. It does not control a user's ability to access elements in that VOB. The element permissions do that.

Ok, that's understood :)

%% >> * When I 'cleartool describe' a vob folder, I only get "User : UNKNOWN and Group: UNKNOWN" information

%% This shouldn't happen unless the user who owns that element can't be looked up from the host you're on. Are you using a non-domain system as the test system?

I am using a computer in the domain and everything; this may be due the different manipulations I did on the VOBs. Once I get the clean method to protect vobs, I will create new test VOBs and see if this problem remains.

%% >> * The only achievements to which I got today were by changing directly the accesses to the ".vbs" folders either for the PVOB or the VOB, without passing by cleartool.

%% Don't do this. You run a better than 90% chance of BREAKING the VOB storage directory permissions. You will become very familiar with the "fix_prot" utility if you persist in doing this.

Good to know. I actually got this kind of errors, and trying fix_prot returned me errors in the permissions messsage.

----

Now the hardest part for me.

%% If this is an all-Windows environment (yes), and you want only authorized users to be able to mount VOBs
I may not have used the correct method previously but so far what I'm doing is using the project explorer to display the different VOBs (from which I can already see the different activities that I would like to hide) and I never "mounted" a VOB, am I doing all wrong?

%%(If users can't mount the VOB, they can't access the contents) try setting up multiple project-specific shares on your VOB server.
"Multiple project specific shares". On my side I am creating One set of VOB/PVOB per project. Then creating "clearcase-named" projects per sub-project (Aouch...this isn't clear..let's say that I have one project to develop an airplane software and another one to develop a pong game, these would be two different VOBS, then if I have two sub-projects within the airplane software project, there I would create two clearcase projects within the VOB), is it the right way to do it?

%% You then grant ONLY the "ClearCase Server process Group" and the group of users access through that share using SHARE PERMISSIONS ONLY.
Are you here mentioning the SHARE PERMISSIONS on the windows environment or another way to handle it? Supposing I have a base cleacase group ccgroup and two other groups that shouldn't have access to every VOB (+ccgp1+ & +ccgp2+), shall I only give SHARE PERMISSIONS to ccgroup and not the others in other to avoid having them seeing the VOB? IS it really sufficient?

%% You may have users who try to get around this using snapshot views, but while they may be able to see the NAMES of the files in the directories, they won't be able to load any of those files into their views.
If they can create views then I suppose that they can see the activites?

%% If you want to limit that, you would have to work with element permissions. The biggest problem here is that you can only work with 16 or 32 groups, depending on the VOB storage platform, and this limits the number of options you have there.

Sorry for all these questions but I feel like I always did the wrong way since I discovered Clearcase...

View the original article here

Re: VOB access control

>> * As far as I understood, Clearcase access control is based on windows access control (right click on a vob folder, security and share...)

Yes and no. Windows access control is only part of the picture. Windows access control it what gets you to the containers in the pools, and what limits your ability to mount a VOB. Beyond that, you're looking strictly at ClearCase permissions, which are more unix-like.

>> * When I add a group through cleartool to the vob, I don't see any change in the windows security window.

Generally speaking, this is normal behavior. You may see the windows permissions on the pool directories change, but not on the .vbs itself. cleartool protect -add_group adds a group to the list of groups that can create or "own" elements within the VOB. That's essentially ALL it does. It does not control a user's ability to access elements in that VOB. The element permissions do that.

>> * When I 'cleartool describe' a vob folder, I only get "User : UNKNOWN and Group: UNKNOWN" information

This shouldn't happen unless the user who owns that element can't be looked up from the host you're on. Are you using a non-domain system as the test system?

>> * The only achievements to which I got today were by changing directly the accesses to the ".vbs" folders either for the PVOB or the VOB, without passing by cleartool.

Don't do this. You run a better than 90% chance of BREAKING the VOB storage directory permissions. You will become very familiar with the "fix_prot" utility if you persist in doing this.

If this is an all-Windows environment, and you want only authorized users to be able to mount VOBs (If users can't mount the VOB, they can't access the contents) try setting up multiple project-specific shares on your VOB server. You then grant ONLY the "ClearCase Server process Group" and the group of users access through that share using SHARE PERMISSIONS ONLY. You may have users who try to get around this using snapshot views, but while they may be able to see the NAMES of the files in the directories, they won't be able to load any of those files into their views. If you want to limit that, you would have to work with element permissions. The biggest problem here is that you can only work with 16 or 32 groups, depending on the VOB storage platform, and this limits the number of options you have there.

=================================================================
Brian Cowan
Advisory Software Engineer
ClearCase SoftWare Advisory Team (SWAT)
Rational Software
IBM Software Group
550 King St
Littleton, MA 01460

Phone: 1.978.899.9471
Web: http://www.ibm.com/software/rational/support/

View the original article here