I am wondering about 'deliverbl', how important are they for historical purposes or during development? All I know is they are created during delivery and includes activies.
If i am exporting major baselines from Clearcase to different SCM, should I consider 'deliverbl' as major baseline?
There are representing merges (from a child stream to another stream), so:
they should be considered, as they show the code "merged" (with potential conflicts resolved)
but you might have more trouble to export the merge hyperlink which shows the source of the merge
I like to export those baselines because their naming convention shows the stream destination name, as well as the date of the deliver, so you are left with clues about a merge between two branches.
However, their are unlabelled, so you might:
either need to convert those to a full baseline (cleartool chbl -full)
or decide to not bother with them and leave those out of your export.
Related
This is a programming language and version control system agnostic question.
There is a source code tree and two patches X and Y. Each of them apply cleanly to the source code tree. But applying one of them (either X or Y first), then another one, results in second patch failing to apply (patches conflict).
Is my only option applying one of them (probably the biggest one, so most of work gets done automatically), then merging the other one by hand and resolving conflicts, or there are better tools/practices to handle this scenario?
The goal is to avoid this situation from happening as there's no easy solution to merge.
In order to avoid, make small commits with their tests and push them to the source repository. Other guys in the team will be forced to pull the latest changes in order to commit their code, and this will ensure that nothing gets broken.
I encourage you to avoid having multiple teams manipulating the same part of the source code. Create a good structure and if possible break down the project into smaller projects.
During merging, TortoiseGit offers a handy GUI to compare changes of both versions with the base file.
After resolving all conflicts and committing them, you can see the changes of a merge commit relative to both parents. Is there also a way to re-show the 3 way merge window for a merge commit from somebody else? Just seeing the individual changes makes it hard to judge, if the merge was performed correctly.
What I see now is two lists where I can check the changes with each parent, what I want is a list that only contains files changed in both branches and where I can see, how these changes where merged together.
I am aware, that I can manually check out the three files, open the three hand merge tool and load them (and delete the files afterwards). However this is rather tedious and not what you want to do, if you just want to quickly check a merge commit.
On my project I have some files that are generated automatically, so you'd normally don't put those in Source Control.
But since this process takes a long time and they change quite periodically, I'd rather keep them in Clear Case database to not impose this process to every one that desires to compile the source that isn't directly related to these files.
So, is there a way that I could add files on ClearCase UCM without creating a version tree?
More directly, I'd like to know if there a way to only one version per branch. As if when delivering this file to the main branch, it would delete the old version an replace it by the new one.
I know that this is a bit unorthodox, but I ask this because I'm not interested by the generated files history and I'd like to save space in the server.
So, is there a way that I could add files on ClearCase UCM without creating a version tree?
No.
Unless those files are radically different from one generation to the next, (or are huge binary), ClearCase would only record the delta, which wouldn't consume too much space.
One trick would be to rename the stream in which the import of the newly generated source is done, and create a new stream, in order to not have a huge version tree over time.
I have two LLGLGEN 2.6 pro source files that I have to merge in my git repo (2 different branches). Due to the "professionnal" work of previous programmers on this project, the two projects have changes (the fork is 1 year old) that are not tracked in documents.
What can be the less painfull solution to finalize my merge ?
Thanks.
In my experience, it's easier to simply ignore the merge conflicts in the LLBL generated code and just re-sync the project to the database and then regenerate the code completely post-merge.
Where this becomes a problem is when there are a lot (or even a few) customizations made to the LLBL project file (e.g renaming fields, creating typed lists). There isn't much you can do about these outside of tracking them down one by one. The good news is the compiler will complain of something is missing or renamed.
The situation is, I once placed some conceptually related codes into one package in hope of interweaving them gradually later, but it turns out they eventually become independent of each other (can be safely separated). Therefore, I decide it's time to split them into different packages, but I'm not sure how to do it in a way so that I could also keep the respective version control history for each sub-package. Any ideas?
The Convert extension included with the standard distribution is used for this purpose. Specifically, check out the --filemap option, which can include, exclude and rename files and directories when converting from one database to another.