On 25 Jul 2008, at 10:58, Lukas Kahwe Smith wrote:
On 25.07.2008, at 11:46, Marcus Boerger wrote:
I mean that if several people work on a changeset, that they still
might want to have a join central repo. Of course dvcs allows direct
exchange of patches as well, but it might still be a good idea to
have
this central dvcs repo for historical reasons (lets say some stuff
is
attempted, it is then abandonded and then picked up by someone
else).
Also in terms of standardization I mean that even core developers
can
get overwhelmed if they end up having to use git here, and hg there.
Then again we are still far away from having that many different
subprojects that need dvcs.
I still cannot follow you. Do you even know about these tools?
I have not used any of them enough in practice to really know them
well.
If two parties use git or hg they are all fine. And everyone else
is fine
too because they don' t have to learn dcms (btw, it's a distributed
cms
as in code/configuraqtion management system:
http://en.wikipedia.org/wiki/Code_management_system). Anyway you
don't want
to teach for example our documentation group to use git or hg.
Besides the
fact thaqt there is no windows support for git they do not have the
slightest use whatsoever for local branching. Though of course
anyone who
is can safely start it's own perfectly working local one.
The point is:
- re2c experimental work used git
We used svn, we converted the 5.3 branch to svn and then did an export
at the end and merged back to CVS.
- mysqlnd used bzr
If I am developer X and for some reason I wanted to be involved in
the re2c and the mysqlnd stuff, then I would need to know both (or
atleast have a stable and easy to use bridge between the two).
This is why I am suggesting to "standardize" on a dvcs.
Also as others have made it more clear than I did in my initial
post. A central place for people to merge their pages upstream makes
it easier for people to join/examine the development (even if the
original people have abonded the effort), without having to hunt
down people to get their changesets. It might also be a convenient
way to prepare before the final push into our central repo. So again
it would be useful to have some default space for teams to place the
"stable" state of their collaboration.
Finally Lars also mentioned that it might be a good idea to keep a
mirror of svn because creating a copy of current svn in some dvcs is
not going to be instant. this again suggests it would make sense for
us to standardize on a specific dvcs or we have to start offering
mirrors for all candidates.
With the svn hooks you can keep a mirror of CVS running and make t
read only apart from commits to the svn repository. Those using
cvsread would then not notice much difference.
Hope I am not too far off-base with these observations ..
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
