How can i move Clearcase dyamic/snapshot views to another host (Linux)
up vote
1
down vote
favorite
i'm about to setup a new server that will be dedicated for CC views i'm wondering if there is any way to move the existing views to the new server?
unix version-control clearcase configuration-management
edited Nov 22 at 14:02
Sneftel
23.5k64077
asked Aug 10 '14 at 12:53
user3502786
1,14492840
add a comment |
up vote
1
down vote
favorite
i'm about to setup a new server that will be dedicated for CC views i'm wondering if there is any way to move the existing views to the new server?
unix version-control clearcase configuration-management
edited Nov 22 at 14:02
Sneftel
23.5k64077
asked Aug 10 '14 at 12:53
user3502786
1,14492840
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
i'm about to setup a new server that will be dedicated for CC views i'm wondering if there is any way to move the existing views to the new server?
unix version-control clearcase configuration-management
edited Nov 22 at 14:02
Sneftel
23.5k64077
asked Aug 10 '14 at 12:53
user3502786
1,14492840
i'm about to setup a new server that will be dedicated for CC views i'm wondering if there is any way to move the existing views to the new server?
unix version-control clearcase configuration-management
unix version-control clearcase configuration-management
edited Nov 22 at 14:02
Sneftel
23.5k64077
asked Aug 10 '14 at 12:53
user3502786
1,14492840
edited Nov 22 at 14:02
Sneftel
23.5k64077
asked Aug 10 '14 at 12:53
user3502786
1,14492840
edited Nov 22 at 14:02
Sneftel
23.5k64077
edited Nov 22 at 14:02
Sneftel
23.5k64077
edited Nov 22 at 14:02
Sneftel
23.5k64077
23.5k64077
asked Aug 10 '14 at 12:53
user3502786
1,14492840
asked Aug 10 '14 at 12:53
user3502786
1,14492840
asked Aug 10 '14 at 12:53
user3502786
1,14492840
1,14492840
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
1
down vote
accepted
In theory, yes: you can unregister a view (cleartool untegister + cleartool rmtag -view), and register it again on the new server.
See:
- "Moving a view to a host with the same architecture or to a NAS device"
- "Moving a view to a host with a different architecture": it involves a
cleartool reformatview -dump/-loadin addition of the unregister/register steps.
(after the more general page "About moving ClearCase servers")
answered Aug 10 '14 at 12:56
VonC
825k28425933126
add a comment |
up vote
0
down vote
Honestly, in the past, I've just found it easier to throw away views and start over. We used a standard set of config specs that created task-specific branches per view. We worked with dynamic views (if you're working with snapshot views in clearcase, I think that you're using the wrong Version Control System), but had our developers checkin all of their changes (which by default would checkin against their feature branch), we'd then delete all of the views for the host being decommisioned, and had developers re-create their views normally (which would automatically start them up on the new server). We naturally abstracted away a lot of the customized config specs and setting up metadata for them so they only needed to run a simple command to continue.
We were not using UCM, however.
Now that I think about it, we just had a small handful of scripts that were used to do this work - basically wraps all of the dirty "view" details away from the developers (which honestly, they don't need to know about in general).
answered Sep 15 '14 at 5:51
Jon V
1815
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
In theory, yes: you can unregister a view (cleartool untegister + cleartool rmtag -view), and register it again on the new server.
See:
- "Moving a view to a host with the same architecture or to a NAS device"
- "Moving a view to a host with a different architecture": it involves a
cleartool reformatview -dump/-loadin addition of the unregister/register steps.
(after the more general page "About moving ClearCase servers")
answered Aug 10 '14 at 12:56
VonC
825k28425933126
add a comment |
up vote
1
down vote
accepted
In theory, yes: you can unregister a view (cleartool untegister + cleartool rmtag -view), and register it again on the new server.
See:
- "Moving a view to a host with the same architecture or to a NAS device"
- "Moving a view to a host with a different architecture": it involves a
cleartool reformatview -dump/-loadin addition of the unregister/register steps.
(after the more general page "About moving ClearCase servers")
answered Aug 10 '14 at 12:56
VonC
825k28425933126
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
In theory, yes: you can unregister a view (cleartool untegister + cleartool rmtag -view), and register it again on the new server.
See:
- "Moving a view to a host with the same architecture or to a NAS device"
- "Moving a view to a host with a different architecture": it involves a
cleartool reformatview -dump/-loadin addition of the unregister/register steps.
(after the more general page "About moving ClearCase servers")
answered Aug 10 '14 at 12:56
VonC
825k28425933126
In theory, yes: you can unregister a view (cleartool untegister + cleartool rmtag -view), and register it again on the new server.
See:
- "Moving a view to a host with the same architecture or to a NAS device"
- "Moving a view to a host with a different architecture": it involves a
cleartool reformatview -dump/-loadin addition of the unregister/register steps.
(after the more general page "About moving ClearCase servers")
answered Aug 10 '14 at 12:56
VonC
825k28425933126
answered Aug 10 '14 at 12:56
VonC
825k28425933126
answered Aug 10 '14 at 12:56
VonC
825k28425933126
answered Aug 10 '14 at 12:56
VonC
825k28425933126
825k28425933126
add a comment |
add a comment |
up vote
0
down vote
Honestly, in the past, I've just found it easier to throw away views and start over. We used a standard set of config specs that created task-specific branches per view. We worked with dynamic views (if you're working with snapshot views in clearcase, I think that you're using the wrong Version Control System), but had our developers checkin all of their changes (which by default would checkin against their feature branch), we'd then delete all of the views for the host being decommisioned, and had developers re-create their views normally (which would automatically start them up on the new server). We naturally abstracted away a lot of the customized config specs and setting up metadata for them so they only needed to run a simple command to continue.
We were not using UCM, however.
Now that I think about it, we just had a small handful of scripts that were used to do this work - basically wraps all of the dirty "view" details away from the developers (which honestly, they don't need to know about in general).
answered Sep 15 '14 at 5:51
Jon V
1815
add a comment |
up vote
0
down vote
Honestly, in the past, I've just found it easier to throw away views and start over. We used a standard set of config specs that created task-specific branches per view. We worked with dynamic views (if you're working with snapshot views in clearcase, I think that you're using the wrong Version Control System), but had our developers checkin all of their changes (which by default would checkin against their feature branch), we'd then delete all of the views for the host being decommisioned, and had developers re-create their views normally (which would automatically start them up on the new server). We naturally abstracted away a lot of the customized config specs and setting up metadata for them so they only needed to run a simple command to continue.
We were not using UCM, however.
Now that I think about it, we just had a small handful of scripts that were used to do this work - basically wraps all of the dirty "view" details away from the developers (which honestly, they don't need to know about in general).
answered Sep 15 '14 at 5:51
Jon V
1815
add a comment |
up vote
0
down vote
up vote
0
down vote
Honestly, in the past, I've just found it easier to throw away views and start over. We used a standard set of config specs that created task-specific branches per view. We worked with dynamic views (if you're working with snapshot views in clearcase, I think that you're using the wrong Version Control System), but had our developers checkin all of their changes (which by default would checkin against their feature branch), we'd then delete all of the views for the host being decommisioned, and had developers re-create their views normally (which would automatically start them up on the new server). We naturally abstracted away a lot of the customized config specs and setting up metadata for them so they only needed to run a simple command to continue.
We were not using UCM, however.
Now that I think about it, we just had a small handful of scripts that were used to do this work - basically wraps all of the dirty "view" details away from the developers (which honestly, they don't need to know about in general).
answered Sep 15 '14 at 5:51
Jon V
1815
Honestly, in the past, I've just found it easier to throw away views and start over. We used a standard set of config specs that created task-specific branches per view. We worked with dynamic views (if you're working with snapshot views in clearcase, I think that you're using the wrong Version Control System), but had our developers checkin all of their changes (which by default would checkin against their feature branch), we'd then delete all of the views for the host being decommisioned, and had developers re-create their views normally (which would automatically start them up on the new server). We naturally abstracted away a lot of the customized config specs and setting up metadata for them so they only needed to run a simple command to continue.
We were not using UCM, however.
Now that I think about it, we just had a small handful of scripts that were used to do this work - basically wraps all of the dirty "view" details away from the developers (which honestly, they don't need to know about in general).
answered Sep 15 '14 at 5:51
Jon V
1815
answered Sep 15 '14 at 5:51
Jon V
1815
answered Sep 15 '14 at 5:51
Jon V
1815
answered Sep 15 '14 at 5:51
Jon V
1815
1815
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f25228796%2fhow-can-i-move-clearcase-dyamic-snapshot-views-to-another-host-linux%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
