Bug #1367
The GitProjectVersion cmake logic requires full git clones
| Status: | Resolved | Start date: | 01/29/2013 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | J. Wienke | % Done: | 100% | |
| Category: | cmake | |||
| Target version: | Robotics Service Bus - rsb-0.7 |
Description
- The logic in GitProjectVersion.cmake requires full clones.
- Not everyone wants to do a full git clone. git also supports shallow copies (--depth=1).
- For large projects such as ffmpeg this is a good option to check out a release branch, since it saves large amounts of traffic.
Additionally it saves a lot of disk space, but it is still possible to use several git features. - Shallow clones are a typical git use case and should be supported by the RSB version logic. Otherwise version information will be lost.
- If he history size of RSB grows, shallow copies can also be used to save disk space on integration servers, etc.
- Attached is also the version.sh in the ffmpeg project which handles these cases.
version.sh 
(1.39 KB)
Associated revisions
Define the latest commit hash for git without git describe.
This is necessary as for shallow copies git describe might fail but we still would like to have commit information in generated packages.
Instead of using git describe now git log is used.
fixes #1367
Backport: Define the latest commit hash for git without git describe.
This is necessary as for shallow copies git describe might fail but we still would like to have commit information in generated packages.
Instead of using git describe now git log is used.
refs #1367
History
#1 Updated by L. Schillingmann about 11 years ago
- File version.sh added
Wrong file. I mean version.sh
#2 Updated by L. Schillingmann about 11 years ago
- File deleted (
version.h)
#3 Updated by J. Wienke about 11 years ago
- Project changed from Robotics Service Bus to Robotics Systems Commons
- Category set to cmake
Ok, they just use a date + hash in case where git describe fails on shallow copies. For our own system we just need to fix that the hash is still passed through in this case, which doesn't work right now. Apart from that I would be fine to leave the patch version at 0, as long as the hash is preserved.
#4 Updated by J. Wienke about 11 years ago
- Status changed from New to In Progress
- Assignee set to J. Wienke
#5 Updated by J. Wienke about 11 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Applied in changeset rsc|commit:4625b1349649817d66edf80cabcb72a644beddd0.