I think that one of the reasons why some people write big monolithic programs with too many classes and functions and just plain stuff in the same headers and .c/.cpp files is that they do not have goopd dynamic Make tools. They get the Makefile working, and then don't touch it, since touching it would require editing by hand.
Tuesday, June 19, 2012
Multihomed workspaces and repos
I often find myself wanting a "multihiomed" workspace or repo:
E.g. a workspace where I push to one or more places regularly.
E.g. I may push to my personal backup or tracking repo.
But occasionally I need to push to a project master.
This becomes complicated when a meta-project is composed of several subrepos - e.g. the main project source, but also source for libraries and tools. Then I want to push the whiole meta-project to the meta-project-repo, the main project (which is a subrepo of the meta-project) to the main project master repo, and the tools and libraries sometimes to the meta-project-repo, and sometimes to their respective master repos.
I can do this by hand, if I remember the names.
But I want to create nice default behavior. Like "push to my backup or m,eta-repo".
And "release all of my changes to rtheir respective providers".
Of course, the respective providers may themselves have flows.
--
I don't see a standard way in hg.
This is partly why I create the CVS.1 CVS.2 ... dirs, long ago.
For now, I am manually recording the multiple homes in files such as meta-repo/subrepo/hg-paths.
Trouyble is, I may not be allowed to asdd stuff like that to meta-repo/subrepo, since that tree belongs to thwe provider.
So I have had to add the metadata about multihoming elsewhere, e.g.
meta-repo/subrepo/hg-paths--for--subrepo.
(I would call it meta-repo/subrepo/hg-paths:subrepo), except I am warned about Windows not liking colons.
E.g. a workspace where I push to one or more places regularly.
E.g. I may push to my personal backup or tracking repo.
But occasionally I need to push to a project master.
This becomes complicated when a meta-project is composed of several subrepos - e.g. the main project source, but also source for libraries and tools. Then I want to push the whiole meta-project to the meta-project-repo, the main project (which is a subrepo of the meta-project) to the main project master repo, and the tools and libraries sometimes to the meta-project-repo, and sometimes to their respective master repos.
I can do this by hand, if I remember the names.
But I want to create nice default behavior. Like "push to my backup or m,eta-repo".
And "release all of my changes to rtheir respective providers".
Of course, the respective providers may themselves have flows.
--
I don't see a standard way in hg.
This is partly why I create the CVS.1 CVS.2 ... dirs, long ago.
For now, I am manually recording the multiple homes in files such as meta-repo/subrepo/hg-paths.
Trouyble is, I may not be allowed to asdd stuff like that to meta-repo/subrepo, since that tree belongs to thwe provider.
So I have had to add the metadata about multihoming elsewhere, e.g.
meta-repo/subrepo/hg-paths--for--subrepo.
(I would call it meta-repo/subrepo/hg-paths:subrepo), except I am warned about Windows not liking colons.
Minor BKM: -comment_knob
I find it convenient to give certain programs a command line option that is just a placeholder, which ignoeres its string argument. Just to hold comments.
Especially useful in a test, so you can say
command -comment_knob 'expect failure' -illegal-option ...
Especially useful in a test, so you can say
command -comment_knob 'expect failure' -illegal-option ...
Subscribe to:
Posts (Atom)