[Phpwm] Time management

[Dave Brotherstone]

On Sun, Apr 17, 2011 at 11:40 AM, Lester Caine <lester at lsces.co.uk> wrote:
> Working on a single module in git is fine ... The main problem I find is
> that the CVS base has some 200 modules - alright 170 or so are probably
> legacy - but the porting over results in 200 repo's and as yet I can't get
> 'super-projects' to work in anything like the way that they do under CVS.
git submodule is probably what you're after / or have tried.  I find
the submodule prinicipal simple and exactly what is needed in many
projects - Project X uses module M. Project Y also uses module M.   3
repositories, X, Y, and M.  X has M as a submodule - which means X has
a link to M at revision "abc". Y has M as a submodule, at revision
"def".  When Project X wants to update to version "def" of M, it
updates it's link, and makes the relevant code changes to X.  When
some other developer does an update, he gets the code changes and the
updated submodule M in one hit.

To me, this solves the age-old problem of two projects using a library
or module at different versions.  Many open source projects use the
submodule feature to include libraries and so on that need a specific
version.


>> CVS was great in it's day. But in
>> comparison to Subversion, git, or hg, it's simply awful.
>
> Actually you already ruled your self out from answering that. Many of the
> 'complaints' about CVS are managed transparently by Eclipse. This handles
> the areas such as managing experimental work. CVS just provides the central
> base to nail down releases. Nailing down a release in git/hg is not nearly
> so easy and need separate cooperation from programmers?

Erm... surely a release will always require cooperation from the
developers - it's just the message changes between CVS/SVN and DCVS
systems - instead of something like "no more commits to branch rel-XY
that aren't serious bug fixes reported from the RC", it's "no more
pull requests will be merged into the rel-XY branch unless they are
serious bug fixes reported from the RC".

Nice that Eclipse hides the complaints/problems with CVS - although
even if I used Eclipse, I'd still like to be able to look in my
repository and understand what was there, outside of my IDE.

> Until you define a
> particular repo as 'master' AND restrict who updates it ;)
Quite. Almost all projects probably have a repo somewhere that is
considered "master" - ie. that that holds the code that creates the
"official" release.  The updates to git repos are obviously usually
initially single-users, therefore you have to explicitly grant the
maintainers list access to update this central repo.  No different
from SVN, apart from it's only a "maintainers" list, not a
"committers" list.  You can have many committers that you don't need
to define anywhere (unlike CVS/SVN), and only a list of maintainers.


> Mind you - discussion options is a little more helpful than "We are using
> git because github is great" - although if it allowed me to download a
> 'production super-project' of repo's as a single hit IN Eclipse then I would
> probably not be arguing :( Today that simply does not work ....

Can't speak for Eclipse obviously, but "git clone url" and "git
submodule update --init" do exactly that.  The same things are
available in Tortoisegit.


> Perhaps we all need to scrap GUI interfaces and return to 'DOS'? I have no
> doubt that everything works fine from the command line - I keep being told
> that :)

Command line FTW! :)

Dave.