At this point it's clear that moving from CVS to SVN for PHP has
become a more or less official project. As such, there is a new
mailing list svn-migration@lists.php.net for anyone who wants to
help with the move. If you're familiar with what I've already done so
far (http://wiki.php.net/svnmigration) and want to help, I beg you
on my knees to subscribe (send a mail to <svn-migration-subscribe@lists.php.net
) and let us know what you want to do :). It's past time for PHP to
make this step a just a little bit further into the future and I hope
we can work together to make it happen.
-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."
On Fri, Jul 25, 2008 at 5:06 AM, Gwynne Raskind
gwynne@wanderingknights.org wrote:
At this point it's clear that moving from CVS to SVN for PHP has become a
more or less official project. As such, there is a new mailing list
isn't better to migrate to git or mercurial ?
http://weblog.rubyonrails.org/2008/4/2/rails-is-moving-from-svn-to-git
it's faster and better on my opinion (why wasting time to convert
later from svn to git )
svn-migration@lists.php.net for anyone who wants to help with the move. If
you're familiar with what I've already done so far
(http://wiki.php.net/svnmigration) and want to help, I beg you on my knees
to subscribe (send a mail to svn-migration-subscribe@lists.php.net) and
let us know what you want to do :). It's past time for PHP to make this step
a just a little bit further into the future and I hope we can work together
to make it happen.-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."--
--
developer flamerobin.org
marius popa wrote:
On Fri, Jul 25, 2008 at 5:06 AM, Gwynne Raskind
gwynne@wanderingknights.org wrote:At this point it's clear that moving from CVS to SVN for PHP has become a
more or less official project. As such, there is a new mailing list
isn't better to migrate to git or mercurial ?
http://weblog.rubyonrails.org/2008/4/2/rails-is-moving-from-svn-to-git
it's faster and better on my opinion (why wasting time to convert
later from svn to git )
We have 1000+ people with commit access, many of whom are not very
technical. We need something with mature Windows tools for those folks
and something that isn't completely different to their way of working.
The git and hg integration with svn is also good so any developer who
prefers to have a local repository can very easily use either git or hg
and easily merge into the central svn repository.
We don't need to be on the bleeding edge of revision control systems.
In fact, I prefer to very much be a very very slow follower in that
particular area to make sure that all tools are extremely mature by the
time we go anywhere near them. The last thing we want to do is slow
down PHP development any further by forcing people to fight with a
bleeding edge set of tools.
When a winner eventually emerges in the de-centralized revision control
world and everyone creates tools for all the various platforms, we'll
have a look, but I predict that to be years away.
-Rasmus
marius popa wrote:
On Fri, Jul 25, 2008 at 5:06 AM, Gwynne Raskind
gwynne@wanderingknights.org wrote:At this point it's clear that moving from CVS to SVN for PHP has
become a
more or less official project. As such, there is a new mailing list
isn't better to migrate to git or mercurial ?
http://weblog.rubyonrails.org/2008/4/2/rails-is-moving-from-svn-to-
git
it's faster and better on my opinion (why wasting time to convert
later from svn to git )We have 1000+ people with commit access, many of whom are not very
technical. We need something with mature Windows tools for those
folks and something that isn't completely different to their way of
working.The git and hg integration with svn is also good so any developer
who prefers to have a local repository can very easily use either
git or hg and easily merge into the central svn repository.
However I think we should provide the infrastructure for developers to
setup a dvcs. I dont know if we want to standardize on a specific one.
But collaboration on exterimental stuff that requires a dvcs should be
possible on php.net servers.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas Kahwe Smith wrote:
The git and hg integration with svn is also good so any developer who
prefers to have a local repository can very easily use either git or
hg and easily merge into the central svn repository.However I think we should provide the infrastructure for developers to
setup a dvcs. I dont know if we want to standardize on a specific one.
But collaboration on exterimental stuff that requires a dvcs should be
possible on php.net servers.
What do you mean by that? hgsvn and git-svn don't need any server-side
support to enable you to work locally and do local git or hg checkins
and then sync to the central svn repository when you are ready.
-Rasmus
Lukas Kahwe Smith wrote:
The git and hg integration with svn is also good so any developer
who
prefers to have a local repository can very easily use either git or
hg and easily merge into the central svn repository.However I think we should provide the infrastructure for developers
to
setup a dvcs. I dont know if we want to standardize on a specific
one.
But collaboration on exterimental stuff that requires a dvcs should
be
possible on php.net servers.What do you mean by that? hgsvn and git-svn don't need any server-
side support to enable you to work locally and do local git or hg
checkins and then sync to the central svn repository when you are
ready.
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.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hello Lukas,
Friday, July 25, 2008, 10:15:08 AM, you wrote:
Lukas Kahwe Smith wrote:
The git and hg integration with svn is also good so any developer
who
prefers to have a local repository can very easily use either git or
hg and easily merge into the central svn repository.However I think we should provide the infrastructure for developers
to
setup a dvcs. I dont know if we want to standardize on a specific
one.
But collaboration on exterimental stuff that requires a dvcs should
be
possible on php.net servers.What do you mean by that? hgsvn and git-svn don't need any server-
side support to enable you to work locally and do local git or hg
checkins and then sync to the central svn repository when you are
ready.
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?
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.
marcus
Best regards,
Marcus
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
- 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.
Hope I am not too far off-base with these observations ..
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
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
mls@pooteeweet.org--
Scott
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.
Ah ok .. the point was just to provide an example that if its a free
for all on what dvcs to use, it can make things harder for people that
join/examine different experimental branches :)
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi Lukas,
We have already had several cases in the past where developers have
collaborated on a CVS branch. The main reason why this hasn't been
common practice is because CVS branching sucks and because some
developers didn't feel comfortable with using branches regardless of the
tool.
I think SVN goes quite far in making development in branches more
productive. I therefore see no reason why mysqlnd and re2c collaborators
could not just use an SVN branch. There is and has never been a rule not
to use branches in the main PHP repository for such collaborations.
My 2 Rappen :)
Andi
Hello Lukas,
Friday, July 25, 2008, 11:58:42 AM, you 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
Hello Marcus;
Marcus Boerger wrote:
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?
I don't presume to speak for Lukas here, nor to believe we should
standardize on one particular alternative VCS (be it a DVCS or not). I
think we should definitely go the SVN route as the only official way to
commit to PHP with possibly a read-only mirror on CVS that could be
phased out at some point in the future.
That said, I think if someone is willing to step up to the plate and
offer bootstrap repositories for another VCS and is willing to help
support it for those who are interested in using it we would be remiss
in turning them down as it's no small undertaking.
According to the wiki there are over 270k commits in php-src. Using
Mono (90k - 100k commits) and my own experience with smaller
repositories (500 - 30k) as a guide, this means that to clone the entire
history of PHP via a git svn clone command would take nearly a week!
Using a bootstrap that is updated nightly, or even weekly, we can cut
that process down to < 15 minutes.
I've already volunteered on the svn-migrations list to work on an
unofficial mirror as soon as the SVN import is completed. I would love
to see it make its way onto a php.net server so others who are
interested can benefit from the upfront work, but will be happy to host
it on one of my servers like the current git clone is.
-T
Hello Travis,
Friday, July 25, 2008, 9:27:02 PM, you wrote:
Hello Marcus;
Marcus Boerger wrote:
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?
I don't presume to speak for Lukas here, nor to believe we should
standardize on one particular alternative VCS (be it a DVCS or not). I
think we should definitely go the SVN route as the only official way to
commit to PHP with possibly a read-only mirror on CVS that could be
phased out at some point in the future.
That said, I think if someone is willing to step up to the plate and
offer bootstrap repositories for another VCS and is willing to help
support it for those who are interested in using it we would be remiss
in turning them down as it's no small undertaking.
According to the wiki there are over 270k commits in php-src. Using
Mono (90k - 100k commits) and my own experience with smaller
repositories (500 - 30k) as a guide, this means that to clone the entire
history of PHP via agit svn clonecommand would take nearly a week!
Using a bootstrap that is updated nightly, or even weekly, we can cut
that process down to < 15 minutes.
I've already volunteered on the svn-migrations list to work on an
unofficial mirror as soon as the SVN import is completed. I would love
to see it make its way onto a php.net server so others who are
interested can benefit from the upfront work, but will be happy to host
it on one of my servers like the current git clone is.
Your help for such a git gateway is probably more than welcome ffrom the
git lovers. Personally I'd probably prefer HG for the task but who knows.
Anyway before we start with that we need to finish the SVN work because
else there is nothing to bridge to. And even though Gwynne has already
done a ton of work we still need to migrate all scripts. And hopefully
we rewrite them all in Python or PHP rather than in Perl which is what
we have right now.
Best regards,
Marcus
Hi Rasmus,
Am Freitag, den 25.07.2008, 01:11 -0700 schrieb Rasmus Lerdorf:
[...]
What do you mean by that? hgsvn and git-svn don't need any server-side
support to enable you to work locally and do local git or hg checkins
and then sync to the central svn repository when you are ready.
git-svn is really slow when you check out a huge repository. And PHP-SRC
will be huge. So it might be worth to export nightly git repos and to
provide a space for developers to create personal repositories from that
nightly repos for collaboration (think re2c, PDO_MYSQLND, etc. pp.)
cu, Lars
Hi Rasmus,
Am Freitag, den 25.07.2008, 01:11 -0700 schrieb Rasmus Lerdorf:
[...]What do you mean by that? hgsvn and git-svn don't need any server-
side
support to enable you to work locally and do local git or hg checkins
and then sync to the central svn repository when you are ready.git-svn is really slow when you check out a huge repository. And PHP-
SRC
will be huge. So it might be worth to export nightly git repos and to
provide a space for developers to create personal repositories from
that
nightly repos for collaboration (think re2c, PDO_MYSQLND, etc. pp.)
BTW: I talked to some mercurial developers at a recent google code
event here in Zurich. They said that their svn bridging is still not
at the same level as that of git, but its being actively addressed.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hello Lukas,
Friday, July 25, 2008, 10:26:59 AM, you wrote:
Hi Rasmus,
Am Freitag, den 25.07.2008, 01:11 -0700 schrieb Rasmus Lerdorf:
[...]What do you mean by that? hgsvn and git-svn don't need any server-
side
support to enable you to work locally and do local git or hg checkins
and then sync to the central svn repository when you are ready.git-svn is really slow when you check out a huge repository. And PHP-
SRC
will be huge. So it might be worth to export nightly git repos and to
provide a space for developers to create personal repositories from
that
nightly repos for collaboration (think re2c, PDO_MYSQLND, etc. pp.)
BTW: I talked to some mercurial developers at a recent google code
event here in Zurich. They said that their svn bridging is still not
at the same level as that of git, but its being actively addressed.
I don't care for slow or fast. Becuase only about 10 people out of a 1000
or so will use any bridge to anywhere. We need to keep our fast development
for php-src, pecl, pear and docs running while improving our development
process at the same time. So far we didn't upgrade anywhere because non of
the tools did offer any real advantage for us - PHP. Subversion is the only
one that is not 10 or a 100 times more complex. In fact for 99% of our
repository users the change will limit to a one time checkout where a
dirrerent repository name, uri or whatever they will name it is being used
and when having to type svn instead of cvs. And as always one should
address the 99% and not the 1%. At leat I for one would prefer not to loose
too many contributers along the way. Either way with subversion 1.5 we get
not only general svn support for transactions and moving but also merge
tracking. Personally the killer feature here is transactions. And I don't
think I have to explain why. But whatever, no other tool is able to provide
what we want while being mature and working on all platforms at the same
timr.
This thread again shows the PHP development. A few people wanting to help
and endless amounts of people needing to mail anything they ever thought
of.
Best regards,
Marcus
However I think we should provide the infrastructure for developers to
setup a dvcs. I dont know if we want to standardize on a specific one.
But collaboration on exterimental stuff that requires a dvcs should be
possible on php.net servers.
Maybe it's just about having the possibilities for developers to share
experimental trees on a php.net side so that people from outside can
pull from it easily and not to remember a bunch of urls to get the trees
of some developers working on interesting patchsets.
Hi,
David Soria Parra wrote:
However I think we should provide the infrastructure for developers to
setup a dvcs. I dont know if we want to standardize on a specific one.
But collaboration on exterimental stuff that requires a dvcs should be
possible on php.net servers.Maybe it's just about having the possibilities for developers to share
experimental trees on a php.net side so that people from outside can
pull from it easily and not to remember a bunch of urls to get the trees
of some developers working on interesting patchsets.
launchpad allows you to create mirror Bazaar repos. The original can be
svn or bazaar. This is how a bzr repo from Launchpad is provided,
although the main repo is svn. Launchpad registration is free and easy.
Best,
Andrey
Oops,
Andrey Hristov wrote:
Hi,
David Soria Parra wrote:However I think we should provide the infrastructure for developers to
setup a dvcs. I dont know if we want to standardize on a specific one.
But collaboration on exterimental stuff that requires a dvcs should be
possible on php.net servers.Maybe it's just about having the possibilities for developers to share
experimental trees on a php.net side so that people from outside can
pull from it easily and not to remember a bunch of urls to get the
trees of some developers working on interesting patchsets.launchpad allows you to create mirror Bazaar repos. The original can be
svn or bazaar. This is how a bzr repo from Launchpad is provided,
should be read as : This is how a MySQL-Proxy bzr repo from Launchpad is
provided :)
although the main repo is svn. Launchpad registration is free and easy.
Best,
Andrey
Andrey
However I think we should provide the infrastructure for developers to
setup a dvcs. I dont know if we want to standardize on a specific one.
But collaboration on exterimental stuff that requires a dvcs should be
possible on php.net servers.Maybe it's just about having the possibilities for developers to share
experimental trees on a php.net side so that people from outside can
pull from it easily and not to remember a bunch of urls to get the trees
of some developers working on interesting patchsets.
Sharing trees can also be done with svn. A repository structure might
look something like that:
root
- active master tees
| + trunk
| + php 5.3
| \ ... - developer trees
| + johannes
| | \ my private play ground
| \ ....
\ archive- php 5.2
- php 5.1
\ ....
svn 1.5 should allow merging between these tree's, but all such things
should be discussed on the other, new list :-)
johannes
P.S. I'm a git fan boy but see good reasons against it for PHP
Rasmus Lerdorf schrieb:
Lukas Kahwe Smith wrote:
The git and hg integration with svn is also good so any developer who
prefers to have a local repository can very easily use either git or
hg and easily merge into the central svn repository.However I think we should provide the infrastructure for developers to
setup a dvcs. I dont know if we want to standardize on a specific one.
But collaboration on exterimental stuff that requires a dvcs should be
possible on php.net servers.What do you mean by that? hgsvn and git-svn don't need any server-side
support to enable you to work locally and do local git or hg checkins
and then sync to the central svn repository when you are ready.-Rasmus
It should not be a question of product, but of workflow. An example: A
lot of time is needed when porting bugfixes from a stable branch to the
development branch and vice versa. In my experience a DVCS reduces this
time immense. PHP-SRC consists of a lot of branches (and tags) and the
goal should be to port code as easy as possible between different branches.
Using a DVCS which is based on a direct acyclic graph (short DAG) can
change the way you work with a VCS. Probably most of you who have worked
with a DVCS know the technique of DaggyFixing
(http://www.venge.net/mtn-wiki/DaggyFixes). Basically it means that a
Bugfix is not committed to the revision where it is fixed, instead the
Bugfix Graph is inserted right after the feature where the problem
occurred and then the merge is propagated to the head revision.
If you take SVN and export it locally to a DVCS, then do some coding and
reimport your patches, this advantages are probably lost (though I have
to admit that I never tried it).
Sebastian
Hello Sebastian,
Saturday, July 26, 2008, 3:59:13 PM, you wrote:
Rasmus Lerdorf schrieb:
Lukas Kahwe Smith wrote:
The git and hg integration with svn is also good so any developer who
prefers to have a local repository can very easily use either git or
hg and easily merge into the central svn repository.However I think we should provide the infrastructure for developers to
setup a dvcs. I dont know if we want to standardize on a specific one.
But collaboration on exterimental stuff that requires a dvcs should be
possible on php.net servers.What do you mean by that? hgsvn and git-svn don't need any server-side
support to enable you to work locally and do local git or hg checkins
and then sync to the central svn repository when you are ready.-Rasmus
It should not be a question of product, but of workflow. An example: A
lot of time is needed when porting bugfixes from a stable branch to the
development branch and vice versa. In my experience a DVCS reduces this
time immense. PHP-SRC consists of a lot of branches (and tags) and the
goal should be to port code as easy as possible between different branches.
Distributed has nothing, nothing, nothing, nothing to do with this.
Distributed means branches, versions and snapshots and personal nonsense
are all on different machines and then one of them gets to be an official
version repository.
That is not in the slightest way compatible with PHP development.
However SVN allows branching and starting with version 1.5 it allows to do
merging across branches and that is what we need. A central repository were
changes can easily be merged from one branch to another.
And as the past months have shown we get more and more bigger taks where
people would like to have there own repositories to play around with and
then merge back. This can easily be done with a bunch of tools bridged to
the one central SVN repository.
We are not Linux with a combined staged and a role/respsonsability model
where even branches are taken from finalized stages to allow branding or
modification for proprietary stuff.
PHP has a flat culture in which everything gets discussed in one way or the
other (mail, irc, phone, live). And all the work is done in a single
central repository.
Using a DVCS which is based on a direct acyclic graph (short DAG) can
change the way you work with a VCS. Probably most of you who have worked
with a DVCS know the technique of DaggyFixing
(http://www.venge.net/mtn-wiki/DaggyFixes). Basically it means that a
Bugfix is not committed to the revision where it is fixed, instead the
Bugfix Graph is inserted right after the feature where the problem
occurred and then the merge is propagated to the head revision.
If you take SVN and export it locally to a DVCS, then do some coding and
reimport your patches, this advantages are probably lost (though I have
to admit that I never tried it).
Sebastian
Best regards,
Marcus
2008/7/25 Gwynne Raskind gwynne@wanderingknights.org
At this point it's clear that moving from CVS to SVN for PHP has become a
more or less official project. As such, there is a new mailing list <
svn-migration@lists.php.net> for anyone who wants to help with the move.
If you're familiar with what I've already done so far (<
http://wiki.php.net/svnmigration>;) and want to help, I beg you on my knees
to subscribe (send a mail to svn-migration-subscribe@lists.php.net) and
let us know what you want to do :). It's past time for PHP to make this step
a just a little bit further into the future and I hope we can work together
to make it happen.-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."--
Hi.
I've been a client user of CVS (php) both SVN and git (strangely enough, for
the same project - PrototypeJS).
As a windows user my observations/opinions are ...
1 - CVS uses a version number for versions of a file and tags when branching
is necessary. From what I can tell a group of change to many files are not
grouped in any obvious way. TortoiseCVS integrates with the Windows Explorer
environment. Command line tools are provided as TortoiseCVS uses them
"behind the scenes". I've also got Cygwin's cvs.
2 - SVN uses a version number for versions of a file and uses directories
when branching is necessary. Groups of changes are connected via a
"changeset". TortoiseSVN integrates with the Windows Explorer environment in
a similar method to that of TortoiseCVS. I've also got Cygwin's svn.
3 - GIT uses a SHA1 hash to group the changes. I find this next to useless
to compare versions as there is no version number per se (at least not one I
can see). I've only got git-gui for Windows. It works very differently to
the Tortoise tools.
Purely from my own experience and knowledge level, I like SVN. I like the
idea of a group of changes being linked. I miss the version numbering (it
may just be that Prototype don't need them ...).
git feels very different to CSV and SVN. It may just be I need to change the
way I see the information provided.
If git can provide in-file version numbering (like CVS does), then that
would feel more comfortable than the SHA1 hashes used.
Richard.
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
On Fri, Jul 25, 2008 at 5:15 AM, Richard Quadling
rquadling@googlemail.com wrote:
As a windows user my observations/opinions are ...
.... taken with a grain of salt. ;-P
Isn't discussion about how to add on to SVN and which tools will
be better-suited for development a decade from now counterproductive
to the idea at hand? SVN and CVS are the industry standard right now,
with SVN being the better-supported and, in many ways, more economical
and prudent approach. I'd be afraid that requiring existing and
future developers to learn newer technologies would stall several
aspects of the project, introduce many new problems, and hinder the
advancement of the language as a whole.
There's no reason other things couldn't be introduced at a later
point, but my personal preference would be to approach the migration
one step at a time. Making small bits of progress over time (while
simultaneously being able to focus on PHP) seems to be more sensible
than trying to radically change everything at once, negating a proven
system in favor of "what might work better."
--
</Daniel P. Brown>
Better prices on dedicated servers:
Intel 2.4GHz/60GB/512MB/2TB $49.99/mo.
Intel 3.06GHz/80GB/1GB/2TB $59.99/mo.
Dedicated servers, VPS, and hosting from $2.50/mo.
On Fri, Jul 25, 2008 at 04:06, Gwynne Raskind
gwynne@wanderingknights.org wrote:
At this point it's clear that moving from CVS to SVN for PHP has become a
more or less official project.
Has the phpdoc revision/translation problem been looked into/fixed?
-Hannes
At this point it's clear that moving from CVS to SVN for PHP has
become a
more or less official project.
Has the phpdoc revision/translation problem been looked into/fixed?
No, not yet, but it will have to be. I intend for discussion on svn-
migration@. For the record, I will more or less ignore discussion that
happens on internals@ on the subject; the idea of making a new list
was to keep noise about the situation out of the ears of people who
don't care. Especially with the 5.3 release coming, the last thing we
need is extra noise without any means of categorizing.
-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."
At this point it's clear that moving from CVS to SVN for PHP has
become a
more or less official project.
Has the phpdoc revision/translation problem been looked into/fixed?No, not yet, but it will have to be. I intend for discussion on svn-
migration@. For the record, I will more or less ignore discussion
that happens on internals@ on the subject; the idea of making a new
list was to keep noise about the situation out of the ears of people
who don't care. Especially with the 5.3 release coming, the last
thing we need is extra noise without any means of categorizing.
Just FYI. I moved the original page with the migration work by Gwynne
and added a landing page that is supposed to pull together all
relevant content (since the conversion of cvs is just one task of many):
http://wiki.php.net/vcs/cvstosvnmigration
In case anyone has any other documents to store in regards to this
general topic it should go into the vcs namespace as well.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org