Hello Lukas, Friday, July 25, 2008, 11:58:42 AM, you 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 no we usde svn > - mysqlnd used bzr I can still contribute to mysql stuff as all that matters is the main repository. If a smaller team forms and decides on bzr or git or hg then they still have to synch with the main repository, be it cvs or svn. We did the same with our re2c development. The advantage of svn over cvs is that we get integration/migration support with the new tools. > 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. There is no need to do so. > 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. > Hope I am not too far off-base with these observations .. A cvs read-only mirror would be nice to allow the old way of checking out stuff. But there I fail to see the reason to limit our selves to one additional other tool, nor do I see a reason to complicate matters even more by giving people other repositories that we somehow merge or not. SVN works everywhere and other tools can be used on top of it where ppl see that necessary but it is not the way PHP is being developed. Or do you want to change the whole of PHP development at the same time? Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
