* Remy Bohmer <[email protected]> schrieb:
Hi,
> > My buildsystem (Briegel) directly checks out the source tree
>
> Sorry, but this sounds like an advertisement...
No, it isnt. That will come one I've finished my paper on it ;-)
> > via git, coming from normalized repositories (eg. canonical
> > version numbers and tags, repo locations, etc) which I maintain
> > in the OSS-QM project.
>
> We do not want to check out complete git trees. We only want to use
> stable released versions of source packages.
In the end, you'll need an complete source tree including certain
fixes. Whether you first fetch and unpack some tarball and apply
(text-based) patchfiles on it or directly check out a given revision
(including the same content) doesn't change the end product ;-P
You can also check out to an different (eg. temporary) workdir easily
(--work-dir option) and you don't need a full clone for that:
git allows to fetch single refs and you can even limit the
retrieved history (--depth option).
The really fine thing here is that you can directly work in the vcs
and let other systems (eg. buildsystems) directly retrieve their
sources from their, w/o the need to maintain separate patch files.
That's eg. really handy when new upstream releases come in and
patches/changes have to be rebased.
Note that git's underlying concepts are very different from traditional
vcs'es like cvs and its successors (svn, etc), and it can be easily
integrated into custom workflows. This article should give an good
introduction:
http://eagain.net/articles/git-for-computer-scientists/
> These source packages sometimes need to be patched with some custom
> patches that we can store in our SCM database.
Custom fixes are easily integratable: just put your own tags into a
separate namespace and let the buildsystem try your namespace first.
Or even always make your own tags - see my paper on the OSS-QM
repos: http://www.metux.de/download/oss-qm/normalized_repository.pdf
> Well, we store the patches, source packages, ptxdist projects and
> tools into the same SCM database as the entire company uses for our
> proprietary sourcecode.
You'd have several options here:
a) put the whole git repos (as such) into your other SCM
b) export the git histories into your SCM (eg. parallel commits
via hooks)
c) export the changes to patches and store them as separate files
in your SCM (also via hooks)
> Every project inside the organisation can find another SCM tool that
> might suit their own projects workflow better, but it is corporate
> wide more efficient to standardise on tools and workflows.
I wouldn't count on that. If you standardize on some tool that is
not optimal for certain jobs (eg. lacks important operations like
rebase), you'll most likely get an suboptimal result ;-p
> Git is a great tool but it has its drawbacks too,
> especially if it needs to be used as a centralised SCM tool.
What drawbacks exactly are this ? In which use cases does git
not play well ?
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: [email protected]
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
--
ptxdist mailing list
[email protected]
