For FL3, I want to do most of the source management in git
repositories, and use CI (continuous integration; most likely
Jenkins) to build source into binaries.
In this model, cvc doesn't go away, but it's much less likely
that you'll use some of its features. For example, if you have a
robot taking content from git and checking it in with cvc commit,
you don't have lots of use for "cvc diff". When it comes to
source code management actions (see "File Operations" in "cvc help")
they will normally either be run by a robot or not needed at all.
(For example, I see multiple git repositories replacing any use
for cvc merge in practice.) The "Information Display" commands
will be useful to see what is in a source component, but in a
more limited scope. Browsing git repository history would replace
"cvc annotate" in workflow; "cvc annotate" would show that the
robot did everything...
One huge exception is that "cvc cook" would need to work without
a CONARY file, in order to work sanely in a git repository. I do
not know how much work that would be.
For developer workflow, let's say you want to update a package to fix a bug.
Right now, you do something like:
cvc co foo
cd foo
edit...
cvc add newpatch
cvc cook
cvc commit
rmake build
Git can be seen as a bit more complicated because git opens up more
options. It's those options, though, that are why the simplicity
of cvc is biting us.
If you have commit privileges in the git repository that the robot watches,
then the equivalent workflow for that bug fix is:
git clone ssh://..../foo
cd foo
edit ...
git add newpatch
cvc cook
git commit -a
...and then Jenkins notices that the git repository has changed,
and fires off the robot, which does any checks (good GPG signature
on tag?) defined, and takes the content currently in Git at that
hash, commits it using cvc, and also using whatever configuration
(inside or outside of that git repository) fires off the correct
rmake command and commits the result.
If you don't have commit privileges to that main git repository,
then you "fork me on github" (whether that's actually github or
not...) and clone the main repository. You commit your change to
your clone repository. Then then you send a pull request, which
is processed by someone who does have commit access to the main
repository, and then things go along as expected.
_______________________________________________
Foresight-devel mailing list
[email protected]
https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
