ClearCase: Can't create folder in branch
Axel Dahmen
we have organized our product versioning in a way that we use a branch to create a so-called Code Freeze version whenever a version of our software goes out into production.
Developments are performed on the "main" branch. Hotfixes on a published version are to be done in the version branch and then eventually merged into the "main" branch.
This is our config_spec for a branch version of "v120":
element * CHECKEDOUT
element * .../v120/LATEST
element * /main/CODEFREEZE.120 -mkbranch v120
load "..."
This works fine so far, but... If we create a new folder while using this config spec, ClearCase tries to create the folder in the "main" branch! So we get an error message stating that the folder can not be found when adding it to ClearCase.
What are we doing wrong? How can we have new folders and files added to a branch only?
Any help is very appreciated!
Thanks,
Axel Dahmen
Andrew DeFaria
element * /main/0to the end of your config spec.
Marc Girod
> If we create a new folder while using this config spec,
> ClearCase tries to create the folder in the "main" branch!
> So we get an error message stating that the folder can not be found when adding it to ClearCase.
>
> What are we doing wrong? How can we have new folders and files added to a branch only?
The problem is that new elements won't have your CODEFREEZE.120
label.
So, the rules you showed us won't apply.
What will apply is something you did not show us,
probably /main/LATEST.
You may want to add a rule to preempt this,
such as;
element * /main/0 -mkbranch v120
instead of the /main /LATEST one.
Isn't this just the usual FAQ?
http://www.cmcrossroads.com/cgi-bin/cmwiki/view/CM/BccFaq1_4_1
Marc
Axel Dahmen
thanks for helping.
Actually the config rules you've mentioned don't cope with the fact that a new folder is falsely created in the "main" branch. The folder should not appear in the "main" branch, it should appear in "v120" branch only - until I merge it into the "main" branch.
Isn't there a config_spec available that automatically creates new folders (and files) in a designated branch?
Again, your help is quite appreciated.
Regards,
Axel Dahmen
---------------
"Marc Girod" <marc....@gmail.com> schrieb im Newsbeitrag news:f6a8fcb8-0898-4b1d...@s50g2000hsb.googlegroups.com...
BAR
Andrew DeFaria
Hi Andrew + Marc,
thanks for helping.
Actually the config rules you've mentioned don't cope with the fact that a new folder is falsely created in the "main" branch.
The folder should not appear in the "main" branch, it should appear in "v120" branch only - until I merge it into the "main" branch.
Isn't there a config_spec available that automatically creates new folders (and files) in a designated branch?
Marc Girod
> Actually the config rules you've mentioned don't cope with the fact that a new folder
> is falsely created in the "main" branch.
In the main branch of what?
I believe you miss something.
There is a /main branch type, but there are as many /main branches
as there are elements.
So, there will in any case be a /main branch of your new directory.
> The folder should not appear in the "main" branch, it should appear in "v120"
> branch only - until I merge it into the "main" branch.
When you create the directory (I avoid the word 'folder' for
consistency), you have to first check out its parent directory, and
this, your config spec will do by default in the v120 branch
(assuming you did drop a CODEFREEZE.120 label on one of its
versions--otherwise, what happens is not defined in the config
spec you showed us, but I take the ellipse as a sign that it was
not complete).
So, your directory should indeed only appear in the v120 branch
of its parent directory.
And nothing forces you ever to merge it into the /main branch.
> Isn't there a config_spec available that automatically creates new folders
> (and files) in a designated branch?
No. No hidden magic. Everything is on the table.
Note for consistency, that you might for fun rename the 'main'
branch type to something else, say 'foo'.
Then, you'd rather change the default config spec to use 'foo'
instead of 'main', otherwise your vob would look empty.
But this would not confuse ClearCase, which would just create
new elements with a /foo/0 version.
Thus, main is special in this topological way, that there is only
one of it. Which is a good reason to avoid using it at all, ever.
And certainly not to merge back to it.
All this is in the FAQ I cited previously.
Marc
Marc Girod
to avoid being told that my English is ununderstandable...
On May 2, 9:33 am, Marc Girod <marc.gi...@gmail.com> wrote:
> There is a /main branch type,
I (obviously) meant: there is a 'main' branch type.
> Note for consistency
And this was for completeness more than for consistency.
I cannot be sure that no other typos are left.
Marc
Axel Dahmen
thanks for trying to help. I appreciate your help very much, particularly as we're facing a blocking problem here.
Here's the problem we have: We're using an automated tool to generate HTML help file from MS Word documents. This tool deletes the target root directory and re-creates a new directory hierarchy with content.
The tool is executed whenever some content changes. By deleting the .\Help\ root directory it always creates \main\0 elements in there.
Here's the problem: We can't possibly track a couple of hundred files and folders in both branches. But ClearCase is currently not allowing us to just remove and re-add content in a version branch and - independent thereof - in the "main" branch as well.
@Andrew:
This is a common and feasible scenario. I can't believe ClearCase doesn't provide a config_spec command to provide for this.
About reading the FAQ:
Our ClearCase expert went to a long-term holiday and we need help on our problem now. I don't have time to read the FAQ now. We need a quick solution to continue working and I've decided to ask the experts here. No offence to anyone pointing me to the FAQ, but I expect not being offended for this decision as well.
Regards,
www.axeldahmen.com
Axel Dahmen
-----------------
"Marc Girod" <marc....@gmail.com> schrieb im Newsbeitrag news:108872ba-1ab7-40d2...@a70g2000hsh.googlegroups.com...
Andrew DeFaria
I have to be very picky with typos in this group, to avoid being told that my English is ununderstandable...
No doubt, faced with this correction, you'll attempt to claim you did it on purpose to be funny. If so let me stop that right now - it wasn't funny and if you thought it was then it is only your humor that is less understood than your grammar!
You choose phrases that native English speakers would not choose but not only that - you wax philosophically about concepts that are not germane to the point and only leave people confused at the end. For example, who cares if you rename /main -> /foo. Nobody would ever do that. It's stupid and fails to help explain the point any further. It's a tangent and an irrelevant and non instructive nor informative one at that. The point is, in CC you need a branch with which to start element creation. CC chooses /main as that branch.
Andrew DeFaria
Part of the inhumanity of the computer is that, once it is competently programmed and working smoothly, it is completely honest. - Isaac Asimov
Marc Girod
> Here's the problem we have: We're using an automated tool
> to generate HTML help file from MS Word documents.
> This tool deletes the target root directory and re-creates a
> new directory hierarchy with content.
Many tools nowadays work in similar SCM hostile ways.
It doesn't come to the mind of their developers that one
might try to understand what happens, and thus to track
differences between configurations.
It is an unfortunate Zeitgeist.
To fight this, your best strategy is probably to run your
tool outside the vobs (maybe on a copy, if the tool needs
to read something from the previous state, before
destroying it, and to update your vob with a tool like
ClearCase::SyncTree, or cleafsimport.
> The tool is executed whenever some content changes.
> By deleting the .\Help\ root directory it always creates
> \main\0 elements in there.
The tool doesn't know anything about ClearCase, right?
So it cannot do a checkout, or a mkelem.
Somehow, you have to do it.
Unless... do you ever check in anything?
Somehow, what you describe remains unclear to me.
You are not doing a recursive check out, run your tool,
recursive check in, are you?
> Here's the problem: We can't possibly track a couple
> of hundred files and folders in both branches. But
> ClearCase is currently not allowing us to just remove
> and re-add content in a version branch and
> - independent thereof - in the "main" branch as well.
ClearCase may help you if you manage the successive
incarnations of your help pages as versions of the
same elements.
This is impossible if everything gets removed.
I guess now you are describing us a case of evil twin
production: you lose all the history every time you run
you tool.
But do do so, you have to run ClearCase commands
(cleartool rmname or the like). Your tool is unlikely to
do that.
> I don't have time to read the FAQ now.
> We need a quick solution to continue working
I didn't point you at 'The F... Manual', but rather at
a precise answer (about /main/0 -mkbranch).
Telling me back why you think it doesn't apply may
help us to understand each other.
Do not assume things are clear once you explain them:
people are often blind to their prejudices, and it is
hard to overcome those so as to build up a shared
context.
Marc
Axel Dahmen
> To fight this, your best strategy is probably to run your
> tool outside the vobs (maybe on a copy, if the tool needs
> to read something from the previous state, before
> destroying it, and to update your vob with a tool like
> ClearCase::SyncTree, or cleafsimport.
As I saw from ClearCase::SyncTree it's a Pearl tool. We're working in a Windows environment here, so I guess this option won't be feasible.
clearfsimport, on the other hand, almost does all the things we need to use, but it doesn't delete obsolete files. And then, there's the question what would happen to a file with the same name in the other branch?
> The tool doesn't know anything about ClearCase, right?
> So it cannot do a checkout, or a mkelem.
> Somehow, you have to do it.
> Unless... do you ever check in anything?
> Somehow, what you describe remains unclear to me.
> You are not doing a recursive check out, run your tool,
> recursive check in, are you?
Right, the tool isn't ClearCase aware. Here're the steps I perform manually so far:
1) Delete .\Help\ in ClearCase Explorer.
2) Run the HelpGenerator tool which creates the new files.
3) Run Microsoft Visual Studio to recursively check in all the files,
because ClearCase Explorer doesn't provide an option to do that.
(Step #3 is performed by excluding all help files from our VStudio project, then re-including all new help files, and finally checking in the project as a whole.)
> ClearCase may help you if you manage the successive
> incarnations of your help pages as versions of the
> same elements.
> This is impossible if everything gets removed.
> I guess now you are describing us a case of evil twin
> production: you lose all the history every time you run
> you tool.
Exactly. The source Microsoft Word document files exist in a versioned form but the resulting, generated HTML/image files currently don't. I didn't come up with any other solution to the generation of multiple image files, depending on the Word documents' content.
> But do do so, you have to run ClearCase commands
> (cleartool rmname or the like). Your tool is unlikely to
> do that.
You are right again... We are working using ClearCase Explorer / Microsoft Visual Studio exclusively. No command line code is executed. I'm afraid we need to focus on our solution and can't deal with command line options. So we use ClearCase Explorer GUI to provide us with context related task suggestions whenever we need to access the repository.
> Telling me back why you think it doesn't apply may
> help us to understand each other.
> Do not assume things are clear once you explain them:
> people are often blind to their prejudices, and it is
> hard to overcome those so as to build up a shared
> context.
I fully agree with you, Marc. Thanks again for your patience.
Do you think you can provide me with a feasible path forward on this?
Best regards,
Axel Dahmen
Axel Dahmen
I get the impression here that you're compensating your aggressions by concentrating on a meaningless discussion.
Do you *REALLY* want us all to read your personal philosophy on English?
Do you *REALLY* think this newsgroup is the right place for that?
Marc is trying to help. He's adding value to the community.
You currently aren't.
Axel Dahmen
Matt
@online.de:
>Marc Girod <marc....@gmail.com> wrote in news:b723f555-acfd-4854-8978-
2f73e1...@w7g2000hsa.googlegroups.com:
Two different suggestions. First, don't use use Visual Studio at all, it's
not really helping you with anything. All of the ClearCase context menus,
should also be available on the windows explorer context menu under
ClearCase. Just go the root directory and do a search for all files.
Select a very large number of them (up to about 300 at a time), right
click-->Add to source control. The windows search is giving you the
recursive nature.
Second, I wouldn't follow the first suggestion or the steps as you describe
them. Instead, I would generate .\Help\ someplace outside of the ClearCase
view. Then, use a tool like WinMerge (open source, free) or some other
compare tool to compare the new .\Help\ to the old one in the view. Then,
just merge the changed files (checking them out to do so). What I don't
know is if when you delete a file through WinMerge, it does the ClearCase
delete or not. It will do the check outs for you if you have an activity
set already. Then run a "find check outs" from the ClearCase context menu
and check in all the changes.
When you install WinMerge, don't pick the ClearCase integration option,
that replaces the ClearCase compare tool for regular ClearCase compares.
But, in the WinMerge options you can tell it to be ClearCase aware.
Matt
tatyana
> Isn't there a config_spec available that automatically creates new folders (and files) in a designated branch?
I believe, you got it already:
element * CHECKEDOUT
element * .../v120/LATEST
element * /main/CODEFREEZE.120 -mkbranch v120
element * /main/0 -mkbranch v120
> > Actually the config rules you've mentioned don't cope with the fact that a new folder is falsely created in the "main" branch.
> In the main branch of what?
And that is the key question here.
> Here's the problem we have: We're using an automated tool to generate HTML help file from MS Word documents. This tool
> deletes the target root directory and re-creates a new directory hierarchy with content.
If your tool deletes, say, Help subdirectory in the root directory, in
order to do that you'd need to checkout the root directory, i.e. to
branch IT out first to the v120 branch (or create a new element of it
in its already existing v120 branch).
And then by deleting every time (by "ct rmname") the Help directory
and re-creating it, your script would create a new element "Help" and
v120 branch of it, which would result in a number of evil twins
(Help@@/main/v120/1).
This isn't perhaps a very good idea in itself, but as a first draft
solution one can do it. And then you would be able, of course, to
compare these twins or merge them to the main branch (of the root
directory!), again - if you really prefer to do so...
I.e. by using the config spec above you'd get something like the
following:
$ ll .@@/main/v120/1/Help/main/v120/1
foo
$ ll .@@/main/v120/2/Help/main/v120/1
bar
$ ll .@@/main/v120/3/Help/main/v120/1
zoo
which you'd be able to compare with:
$ ll .@@/main/CODEFREEZE.120/Help/CODEFREEZE.120
zar
That's not a very elegant way of doing things, though. So, later you
can consider modifying your tool functionality so that it only updates
the changed elements in the Help directory instead of re-creating the
directory itself every time from scratch.
Marc Girod <marc.gi...@gmail.com> wrote:
> and to update your vob with a tool like ClearCase::SyncTree, or cleafsimport.
Indeed, ClearCase::SyncTree would be a good tool for doing that (it
works on Windows as well, on top of Active Perl), and consider, of
course, using it in a dynamic view.
Tanya.
Andrew DeFaria
Andrew,
I get the impression here that you're compensating your aggressions by concentrating on a meaningless discussion.
Do you *REALLY* want us all to read your personal philosophy on English?
Do you *REALLY* think this newsgroup is the right place for that?
BTW: The same can be said about your attempt of admonishment here. I mean I can charge you with the exact same crime (compensating your aggressions by concentrating on a meaningless discussion - whatever that means!) and that do you really want us all to read your personal critic of me and all...
Marc is trying to help. He's adding value to the community.
You currently aren't.
Andrew DeFaria
As I saw from ClearCase::SyncTree it's a Pearl tool.
We're working in a Windows environment here, so I guess this option won't be feasible.
Differences between synctree and citree include:Of course I'm sure you'll see my answer as unhelpful because I had previously mentioned Marc communication problems... (Makes sense I guess...)
1. Synctree works on Windows as well as UNIX.
clearfsimport, on the other hand, almost does all the things we need to use, but it doesn't delete obsolete files. And then, there's the question what would happen to a file with the same name in the other branch?
ClearCase may help you if you manage the successive incarnations of your help pages as versions of the same elements.Exactly. The source Microsoft Word document files exist in a versioned form but the resulting, generated HTML/image files currently don't. I didn't come up with any other solution to the generation of multiple image files, depending on the Word documents' content.
This is impossible if everything gets removed. I guess now you are describing us a case of evil twin production: you lose all the history every time you run you tool.
Stated differently, generally, if foo.c produces foo.o as a result of a build then you VC foo.c but you do not VC foo.o. Given that model, why then are you attempting to VC the generated HTML/image files?
But do do so, you have to run ClearCase commands (cleartool rmname or the like). Your tool is unlikely to do that.You are right again... We are working using ClearCase Explorer / Microsoft Visual Studio exclusively. No command line code is executed. I'm afraid we need to focus on our solution and can't deal with command line options. So we use ClearCase Explorer GUI to provide us with context related task suggestions whenever we need to access the repository.
Andrew DeFaria
Indeed, ClearCase::SyncTree would be a good tool for doing that (it works on Windows as well, on top of Active Perl), and consider, of course, using it in a dynamic view.
Marc Girod
> Why not simply use ccperl, which you're guaranteed to have if you have
> Clearcase?
Because:
- you cannot add modules to it (not even CtCmd)
- it used to be built without debug support
- in all versions of ClearCase, it is an old version of perl (got
better with 7.x though).
Don't do that. Bad advice.
Marc
Andrew DeFaria
On May 3, 3:22 am, Andrew DeFaria <And...@DeFaria.com> wrote:
Why not simply use ccperl, which you're guaranteed to have if you have Clearcase?Because:
- you cannot add modules to it (not even CtCmd)
- it used to be built without debug support
- in all versions of ClearCase, it is an old version of perl (got better with 7.x though).
Don't do that. Bad advice.
Marc Girod
> The only bad thing is not being able to add modules to it.
Even if one could, the whole perl goes away at upgrades,
and your modules would go with.
I'll add this not using ClearCase perl to the FAQ,
as many people do it as it is an appealing idea at first.
Marc
Axel Dahmen
thanks for your suggestion.
Yet, we are *using* VStudio as our primary development environment. Not using it is not feasible.
I regard doing a Merge, a diff or anything else as to awkward. Until now I expect ClearCase to do this automatically, like Visual Source Safe, TFS and others do. Visual Studio does the checking in quite good.
Currently, Visual Studio is not the problem we are facing, it's ClearCase and its missing functionality in correctly administering branches, as far as I can see.
Do you perhaps have some other suggestion? It must be possible to delete files in a branch without affecting the other branches.
TIA,
Axel Dahmen
"Matt" <m...@m.mmm> schrieb im Newsbeitrag news:Xns9A92A6E3C6...@69.28.186.121...
Axel Dahmen
> Additionally, from http://search.cpan.org/src/DSB/ClearCase-SyncTree-0.47/README:
I see...
> That'd be called an Evil Twin and you really don't want
> to be creating them.
Although Marc has mentioned this as "Evil Twin" as well, I regard this as an pejorative denomination. Different branches may contain a different set of files. It must be possible to create and delete files in a branch without affecting or even regarding other branches.
> ClearCase may help you if you manage the successive incarnations of your
> help pages as versions of the same elements.
How about versions of new elements? And how about versions of elements that must be deleted from a branch's folder?
> IMHO if the resulting HTML/image files are indeed generated then they
> should not be in VC! They can always be generated given the source input.
> Isn't that really why we use VC?!?
I think so to. BUT... They are part of the solution we provide for production. And we're discussing about a general problem here. How about deleting and creating files in different branches in general? I need a general solution to provide to my co-workers. They should not have to deal with ClearCase peculiarities. They must concentrate on the solution they are building. I need a general solution that would cope with the same problem that might occur on other - versioned - files as well. Our help files is just the first impact where this branching problem occurred.
> Shunning the command line is the bane of most shops. There is absolutely nothing wrong with a command line!
No one said that it would be. It's just have the way to a GUI driven, context sensitive surface. Instead of studying a tool thoroughly, developers need to focus on their own solution. That's their task. A good tool provides a context sensitive GUI to suggest a tool's options to a developer when it's required. That a GUI's advantage. Nothing more. And EOL.
Regards,
Axel Dahmen
Axel Dahmen
thanks for helping!
So the config_spec you've given below would actually be a solution to our problem? That would be great!
Please allow for a few questions (pardon me again for not being a ClearCase expert):
If I delete all files in ./Help/ in the v120 branch, wouldn't it affect files in the "main" branch as well? And vice versa?
I don't want to compare anything from the branches, at least none of these help files. I just want to re-create them whenever required, add them to our Visual Studio web project (and hence to our ClearCase VOB) and forget about them.
Same for other files in the future. Whenever one of my colleagues believes a file isn't feasible for a branch, he should be able to just delete that file in that branch, yet be able to keep it in any other branches or the "main" branch. And he should be able to add new files to a particular branch without affecting other branches or the "main" branch.
Would the config_spec you've suggested do this?
Your help is quite appreciated.
TIA,
Axel Dahmen
------------------------------
"tatyana" <tshp...@narod.ru> schrieb im Newsbeitrag news:15e8ed19-fac9-47e2...@b1g2000hsg.googlegroups.com...
BAR
> Hi Matt,
>
> thanks for your suggestion.
>
> Yet, we are *using* VStudio as our primary development environment. Not using it is not feasible.
> I regard doing a Merge, a diff or anything else as to awkward. Until now I expect ClearCase to do this automatically, like Visual Source Safe, TFS and others do. Visual Studio does the checking in quite good.
>
> Currently, Visual Studio is not the problem we are facing, it's ClearCase and its missing functionality in correctly administering branches, as far as I can see.
ClearCase is one of the only if not the only VCS systems that correctly
versions files and directory elements. You need to doe more reading
toward a better understanding of what ClearCase does, how it does it and
why it is vastly different from other VCS systems.
> Do you perhaps have some other suggestion? It must be possible to delete files in a branch without affecting the other branches.
In the ClearCase paradigm there are no files and directories on
branches. There are only versions of elements, files and directories in
branches. Once you get your head wrapped around this you will better
understand whey there always has to be a /main/0 version for each element.
Axel Dahmen
you've got a quite insulting style of writing. I'm not a regular in this newsgroup. Perhaps how and what you write is regarded as being funny. I don't know. But I've got the impression that you're kind of a troublemaker. Perhaps others got acquainted to your kind of writing. If Marc's allright with it, I am as well.
>> You currently aren't.
> Actually I am - and you should really take back your insult here.
I've intentionally written that you "currently" aren't. Thereby I didn't regard to your previous posting, which was quite of value. Though not a source of further value as you've written "end of story".
Regards,
Axel Dahmen
Axel Dahmen
> ClearCase is one of the only if not the only VCS systems that correctly
> versions files and directory elements. You need to doe more reading
> toward a better understanding of what ClearCase does, how it does it and
> why it is vastly different from other VCS systems.
I don't have the time, I'm afraid. Otherwise I wouldn't be asking my questions here. Our expert is gone until end of May.
> > Do you perhaps have some other suggestion? It must be possible to delete files in a branch without affecting the other branches.
>
> In the ClearCase paradigm there are no files and directories on
> branches. There are only versions of elements, files and directories in
> branches. Once you get your head wrapped around this you will better
> understand whey there always has to be a /main/0 version for each element.
For me it would be perfectly sufficient to get a functioning config_spec. Although I'd surely love to, I can't afford the time for reading into ClearCase yet.
Do you have a good config_spec suggestion at hand? Or would you support Tatyana's suggestion?
TIA,
Axel Dahmen
BAR
You need to stop interchanging file and version. ClearCase has elements,
directory elements and file elements. Elements have branches and those
branches haves versions. You cannot delete a file from a branch.
Wholesale deleting of directory structures is, such as your ./help/.
directory is not a good practice. You should either have it generated as
others have suggested or you should have newer versions checked in over
top of existing versions.
Dirk Heinrichs
> You need to stop interchanging file and version. ClearCase has elements,
> directory elements and file elements. Elements have branches and those
> branches haves versions. You cannot delete a file from a branch.
Yes, you can. Precisely: A file element can be deleted from a version on a
branch of its parent directory element.
In that sense, a branch (of a directory element) has files (and other
directories).
Bye...
Dirk
--
Dirk Heinrichs | Tel: +49 (0)162 234 3408
Configuration Manager | Fax: +49 (0)211 47068 111
Capgemini Deutschland | Mail: dirk.he...@capgemini.com
Wanheimerstraße 68 | Web: http://www.capgemini.com
D-40468 Düsseldorf | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: www.keyserver.net
BAR
> BAR wrote:
>
>> You need to stop interchanging file and version. ClearCase has elements,
>> directory elements and file elements. Elements have branches and those
>> branches haves versions. You cannot delete a file from a branch.
>
> Yes, you can. Precisely: A file element can be deleted from a version on a
> branch of its parent directory element.
>
> In that sense, a branch (of a directory element) has files (and other
> directories).
The reference to a version of a file element or directory element can be
removed from a directory version on a branch.
Andrew DeFaria
On May 3, 6:30 pm, Andrew DeFaria <And...@DeFaria.com> wrote:
The only bad thing is not being able to add modules to it.Even if one could, the whole perl goes away at upgrades, and your modules would go with.
I'll add this not using ClearCase perl to the FAQ, as many people do it as it is an appealing idea at first.
Axel Dahmen
Actually I don't think *deleting* is the problem here as I get a message from ClearCase Explorer stating that deleting elements is just more or less a "rename". So I guess deleting a folder or file element in a branch doesn't affect other branches. (Just guessing here...)
My problem comes to *adding* a folder or file to a branch. Because these seem to always being added to the "main" branch. And here comes the trouble if such file already exists in the main branch but not in the branch I'm trying to add a file to.
If Tatyana's, Andrew's and Marc's config_spec all cope with this problem, I'm fine. I'm off now to the office to check that.
We've now decided to keep the help file generation out of ClearCase. But the overall question remains: What will happen in the above mentioned scenario?
Thanks again for all of those replying and answering this thread!
Regards,
Axel Dahmen
-----------------------
"BAR" <Scre...@Your.Place> schrieb im Newsbeitrag news:rtSdnelTU9UakILV...@comcast.com...
Andrew DeFaria
That'd be called an Evil Twin and you really don't want to be creating them.Although Marc has mentioned this as "Evil Twin" as well, I regard this as an pejorative denomination.
Different branches may contain a different set of files. It must be possible to create and delete files in a branch without affecting or even regarding other branches.
ClearCase may help you if you manage the successive incarnations of your help pages as versions of the same elements.How about versions of new elements?
And how about versions of elements that must be deleted from a branch's folder?
Perhaps it might be helpful for you to understand that you can view versioning of directories as a directory is just a list of the files and directories contained in it. If a new file element comes into existence you need to alter the list of files kept in the parent directory. Effectively you need to check out the parent directory, add the element to the list and check in the parent directory. This produces a new version of the parent directory. And if you diff it to the previous version you'll see effectively a list of elements in the parent directory where the new version has one additional entry.
Similarly if you delete an element with rmname a similar thing happens.
IMHO if the resulting HTML/image files are indeed generated then they should not be in VC! They can always be generated given the source input. Isn't that really why we use VC?!?I think so to. BUT... They are part of the solution we provide for production.
And we're discussing about a general problem here.
How about deleting and creating files in different branches in general?
I need a general solution to provide to my co-workers.
They should not have to deal with ClearCase peculiarities.
They must concentrate on the solution they are building. I need a general solution that would cope with the same problem that might occur on other - versioned - files as well. Our help files is just the first impact where this branching problem occurred.
What problems some people have WRT Clearcase is often a combination of misunderstanding what Clearcase is already doing (often under they guise that they don't have to time to spend to understand the tool they're working with in the first place) and a blind insistence of doing something in a manner that is not conducive to how the tool was designed to run (you shouldn't be trying to version control your generated help files).
It amazes me when people ask for advice and other people who have expertise on the topic at hand fail to heed the advice. Look if you want to continue to pound you head with that sledgehammer after you asked me what would I do and I tell you "I'd stop hitting myself in the head with that hammer" then by all means go right ahead. There's nothing more I can do to help you
Shunning the command line is the bane of most shops. There is absolutely nothing wrong with a command line!No one said that it would be.
It's just have the way to a GUI driven, context sensitive surface.
Instead of studying a tool thoroughly, developers need to focus on their own solution. That's their task.
Granted, study it enough to know how to use it I guess. But the fact that you are coming here with the questions you have suggests you do not know how to use it enough. And yes I understand that your expert is gone. Sounds to me like you might want to get him on the horn if you do not like our solution.
A good tool provides a context sensitive GUI to suggest a tool's options to a developer when it's required. That a GUI's advantage. Nothing more. And EOL.
There you have context sensitive help at the command line. Search for a term.
While I admit that a GUI tool could provide some additional and perhaps intuitive help (and there are many examples of bad GUI design as well) it is not the same to day that the command line should be avoided entirely. Your comments suggest a disdain for anything command line related. You don't know how many times I see computer writers, for example, judge a distribution of Linux based on whether or not one must drop to the dreaded command line to install it. If you have to do that then you're getting a bad review - period.
Andrew DeFaria
Andrew,
you've got a quite insulting style of writing.
I'm not a regular in this newsgroup. Perhaps how and what you write is regarded as being funny.
I don't know. But I've got the impression that you're kind of a troublemaker.
BTW: I told you that solution, so did Marc and even Tanya reiterated it once again. And to Tanya you ask "will that really work" hinting that you haven't even tried it yet! Because had you you wouldn't be asking or at least you'd be asking different questions by now. So, whose being helpful and whos' making trouble?
Perhaps others got acquainted to your kind of writing. If Marc's allright with it, I am as well.
You currently aren't.
Actually I am - and you should really take back your insult here.I've intentionally written that you "currently" aren't. Thereby I didn't regard to your previous posting, which was quite of value. Though not a source of further value as you've written "end of story".
Oh and thanks for taking back your insult. It was duly noted... :-P
Marc Girod
Back from a long week-end (bank holiday in Ireland).
On May 5, 3:58 pm, "Axel Dahmen" <NO_S...@NoOneKnows.invalid> wrote:
> Just guessing here..
I advise you to spend time and effort to understand the problem.
This will pay back, and save you time on the whole.
I'll try to model on a simple command line case the effects you
get.
> If Tatyana's, Andrew's and Marc's config_spec all cope with this problem, I'm fine.
As mentioned earlier, branches are only a side aspect here.
A config spec will not help you more than to push this aspect
away and to disclose the evil twin problem in a cleaner context.
Back soon.
Marc
Marc Girod
On May 6, 10:34 am, Marc Girod <marc.gi...@gmail.com> wrote:
> I'll try to model on a simple command line case the effects you
> get.
Unfortunately, I fail to reproduce what I was thinking of on Unix.
So, either my model was wrong, or there is a Windows
specific component in it (bound to the integration with Visual
Studio).
Here is what I tried (as simple as possible...):
$ pwd
/vobs/atcctest/foo
$ ct ls -r .
d@@/main/1 Rule: /main/
LATEST
./d/f@@/main/0 Rule: /main/
LATEST
$ ct co -nc . d d/f
Checked out "." from version "/main/2".
Checked out "d" from version "/main/1".
Checked out "d/f" from version "/main/0".
$ rm -rf d
rm: Unable to remove directory d: Read-only file system
I.e. my setup is:
- one 'root' directory
- one sub-directory
- one file in the latter.
I check-out everything,
and do a recursive removal (which is what I understand your tool
does).
On unix, this is done with 'rm -rf' (which would remove both files and
directories).
Unfortunately (for our reproduction), this fails to remove the
directories.
I believe that the Windows equivalent works (which causes the evil
twin problem in this setup), especially from your GUI.
Can you confirm?
Marc
Marc Girod
> Unfortunately (for our reproduction), this fails to remove the
> directories.
I mean that my situation at that point is:
$ ct ls -r .
d@@/main/CHECKEDOUT from /main/1 Rule:
CHECKEDOUT
./d/f@@/main/CHECKEDOUT from /main/0 [checkedout but removed]
$ ct ls -d .
.@@/main/CHECKEDOUT from /main/2 Rule:
CHECKEDOUT
[Grml... this -r which doesn't include the current directory!]
As you see, the file is marked as removed, but since the directory
is still there, the original element is still correctly referenced.
Droping new data under this name will bind to the same element,
and get checked in as a new version.
In order to get an evil twin pattern in this setup, we'd need to
remove the directory as well, and with it the reference to the
original file.
I am afraid this is prevented in Unix.
How about the Windows/Visual Studio integration?
I don't think it is worth my trying to reproduce this in a Windows
command line.
Or maybe... Unix is orthogonal, so that rmdir won't help (does the
same as rm -rf).
It may be different on Windows...
Marc
Marc Girod
> It may be different on Windows...
Looks it is not. Unless you Visual Studio manages to be
more brutal?
Z:\atcctest\foo>"c:\program files\rational\clearcase\bin\cleartool" ls
-r .
d@@\main\CHECKEDOUT from \main\1 Rule:
CHECKEDOUT
.\d\f@@\main\CHECKEDOUT from \main\0 Rule:
CHECKEDOUT
Z:\atcctest\foo>"c:\program files\rational\clearcase\bin\cleartool" ls
-d .
.@@\main\CHECKEDOUT from \main\2 Rule:
CHECKEDOUT
Z:\atcctest\foo>del /f/s *
Z:\atcctest\foo\*, Are you sure (Y/N)? y
Z:\atcctest\foo\d\*, Are you sure (Y/N)? y
Deleted file - Z:\atcctest\foo\d\f
Z:\atcctest\foo>dir
Volume in drive Z is CCase
Volume Serial Number is 0234-5789
Directory of Z:\atcctest\foo
06/05/2008 10:36 <DIR> .
11/04/2008 18:13 <DIR> ..
06/05/2008 12:07 <DIR> d
0 File(s) 0 bytes
3 Dir(s) 524,288,000 bytes free
Z:\atcctest\foo>rmdir d
The media is write protected.
Marc
Axel Dahmen
As suggested from several people here, I've amended our config_spec to:
element * CHECKEDOUT
element * .../v120/LATEST
element * /main/CODEFREEZE.120 -mkbranch v120
new => element * /main/0 -mkbranch v120
And everything works perfectly well now, in the branch as well as in the "main" branch.
@Marc:
In our scenario VS is doing nothing more than just adding files/folders to source control recursively. Anything else is done manually by us. Actually it's adding files one by one so it often takes quite a while to check in things. But it's better than doing it manually ourselves.
Regarding the Evil Twin scenario:
To me Read_Me files are a typical situation where "Evil" Twins are a requirement. There is no history between branches, Read_Me files just apply to their branch. Yet, within a branch, they need to have a history.
I can't stress enough how much I appreciate the help from all of you. And I apologize for not being able to dig any further into ClearCase myself.
I regard this issue as being solved now. Thanks to your valuable information.
Best regards,
www.axeldahmen.com
Axel Dahmen
---------------
"Marc Girod" <marc....@gmail.com> schrieb im Newsbeitrag news:b00e32e0-004a-4262...@k37g2000hsf.googlegroups.com...
Andrew DeFaria
Axel Dahmen wrote:
First of all: Thanks to everyone spending their time on helping!
As suggested from several people here, I've amended our config_spec to:
element * CHECKEDOUT
element * .../v120/LATEST
element * /main/CODEFREEZE.120 -mkbranch v120
new => element * /main/0 -mkbranch v120
And everything works perfectly well now, in the branch as well as in the "main" branch.
@Marc:
In our scenario VS is doing nothing more than just adding files/folders to source control recursively. Anything else is done manually by us. Actually it's adding files one by one so it often takes quite a while to check in things. But it's better than doing it manually ourselves.
Regarding the Evil Twin scenario:
To me Read_Me files are a typical situation where "Evil" Twins are a requirement. There is no history between branches, Read_Me files just apply to their branch. Yet, within a branch, they need to have a history.
I can't stress enough how much I appreciate the help from all of you. And I apologize for not being able to dig any further into ClearCase myself.
I regard this issue as being solved now. Thanks to your valuable information.
Axel Dahmen
> You're welcome. But remember I gave you the answer first ('cept I missed
> the -mkbranch). Next time try not being so harsh on me.
Hi, Andrew,
I'd particularly like to thank you for your efforts. You are right, you've been the first to point me to the correct solution. And it proved to be the correct one right from the start.
Nonetheless I'm also very thankful for all others having the patience taking their time to explain to me (as a completely ignorant ClearCase user) where my error in thinking was, (e.g. that /main/0 is something special). That gave me a good feeling to use this config_spec at all and not to make any mistake by probably being misunderstood.
Thanks again, Andrew!
Take care,
www.axeldahmen.com
Axel Dahmen
Andrew DeFaria
Unfortunately many tech people seem to have chips on their shoulders and fire off quickly and rudely at the start. I have the unfortunate habit of responding in kind. Later on down the road others forget what happened first and how we got to this place. As I said, many tech people don't seem to have the courage to admit when they were wrong or started something - they have the zeal to be right... at all costs.
If one looks back to where this little tiff between Marc and I started it started with me simply saying "I didn't understand a word that you said". I didn't say it to bemoan Marc or insult him, I said it to inform him that to me, and perhaps others, it didn't seem to make sense. I know Marc's native language is not English and he sometimes states things that a native English speaker (i.e. me) finds oddly worded or worded in a confusing manner. I offered him help.
However, Marc choose to see this an attack on his intelligence and attacked back. Now it's a thing for him and he decided to bring his anger/hurt/embarrassment into this unrelated thread for which you had to suffer. Shame on Marc!
I'm glad to see it's working for you now.