better changeset tracking

Stanislav Malyshev wrote:

Switching to subversion would mean a learning curve for some, and a
change of PHP development tools and practice for everyone involved
in php.net. It's a major step, particularly at a time when people are

I used to think so, but my experience working with SVN on Framework
shows it's not that different, at least on the level I use it (and
that'd be the level most other people would use it I guess -
checkout/update/diff/commit). So if we talking learning curve, it's not
that different - svn up vs. cvs up :) I don't know though how (and if at
all possible) to port karma system, changelog, etc. but that's admin
stuff already.

Would be nice if svn already had versioning for metadata, but otherwise
it's not that hard to learn (there are even tricks to jump your live tree
from a cvs checkout to an svn checkout, although a cvs diff/svn checkout
and patch is usually simpler.)

The ASF finally set a hard cutoff, and forced the hand. People adapted.
In other works, "svn doesn't suck" :) It's just a slightly different
tool. svn status is a huge improvement over cvs up to locate the diffs
in your current checkout. svn 1.4 finally gives you the chance to
mirror the repository. E.g. if you could do it in cvs, you can do it
(somehow) finally in svn.

The problem, as Rasmus points out, is that a huge repository like php's
naturally doesn't migrate cleanly, and that's not even pointing out the
nightmares of fat fingers crawling around rcs ,v files.

Hi Stas,

I used to think so, but my experience working with SVN on Framework shows
it's not that different, at least on the level I use it (and that'd be the
level most other people would use it I guess -
checkout/update/diff/commit). So if we talking learning curve, it's not
that different - svn up vs. cvs up :) I don't know though how (and if at
all possible) to port karma system, changelog, etc. but that's admin stuff
already.

It's different if you're someone who doesn't really know what a CVS is and
just uses the tool mechanically. That's probably most of the translation
teams, some of the documentation teams, a fair proportion of the PEAR and
smarty folk.... It's a new tool. Windows-based docs people need to use
cygwin to generate a test build on their home pc, so it's a fair bet that
most of them will be using commandline cvs without actually understanding
it. For svn they'll all be downloading something else they don't really
understand (or need to), but that's intimidating for doze people - usually
downloading anything via cygwin means downloading about another 8 things
that you've no idea about (dependencies). It's actually easier for the
coding teams because they can just use tortoisesvn...

Anyway this is 'future talk' so I'll stave off the panic for now :)

• Steph

Hello Rasmus,

I wouldn't expect much problems from converting to SVN. What we have to
analyse is how well it can handle all the directoy linking and stuff we
did to overcome the CVS disadvantages. I changed a few repositories my self
and never experienced any issues. Also we are friends with most of the
important developers of SVN so we might be able to get some help. And Last
but not least, if we think about putting a new toolchain on top of what we
have, why bother with old crap then? Just move to where the development
happens. CVS will imho die. And right now the only thing I was missing
from SVN with branch graphs. That is curretnly not possible in SVN but as
far as I know it will be with 1.5. When the import tool is using 1.5 we
should get all we want from the conversion. So why not look for what we
want to do in the future with SVN as the base tool. I also agree to what
Wez said. A few more columns in the bugs database would help a lot. And
last but not least bug numbers could contain something like P for PHP,
L for PECL and R for PEAR. That way it is clear where they came from.
Another way is to extend them with a first digit and then merge the
tables. It is imho a very bad thing to have three databases for bugs.

best regards
marcus

Wednesday, May 30, 2007, 8:04:20 AM, you wrote:

Also keep in mind that the manual tweaks to the CVS repository over the
past 10+ years means we will likely lose commit history. Last time I
tried the conversion process over a year ago, the commit history was
completely hosed. We will eventually need to migrate, but we have to
recognize that it is going to hurt on many levels.

-Rasmus

Steph Fox wrote:

Ouf... Wez and I may have different ideas here, but we were both aiming
to keep it simple. That's because we both know that if it turns into a
big job/makes life more complicated for the dev team, nobody will find
the time or inclination to implement it anyway!

Switching to subversion would mean a learning curve for some, and a
change of PHP development tools and practice for everyone involved in
php.net. It's a major step, particularly at a time when people are
finding themselves stretched anyway (the starting point of this entire
issue). Besides, the whole issue of PECL branch, commit and bug
reporting mechanisms needs some serious thought beforehand, because
there are so many niggling problems there. It'd be better to resolve
those problems (at least in a theoretical sense) before the move than
after.

So yeah - a huge job, and not only from the repository admin perspective.

• Steph

----- Original Message ----- From: "Andi Gutmans" andi@zend.com
To: "Rasmus Lerdorf" rasmus@lerdorf.com
Cc: "Wez Furlong" kingwez@gmail.com; "Ilia Alshanetsky"
ilia@prohost.org; "Edin Kadribasic" edin@krug.dk; "PHP Internals
List" internals@lists.php.net
Sent: Wednesday, May 30, 2007 6:18 AM
Subject: RE: [PHP-DEV] better changeset tracking

Well I think Subversion the way it is today is already considerably
better. Just the directory versioning and the better performance would
already pay off in the PHP project.
No doubt that merge tracking is an added bonus but it's not exactly
applicable (yet) to the way we work in the project as we are mainly
doing selective merges. It would require us to somewhat rethink how we
want people to develop (i.e. branch per major feature, branch per mini
release, etc...).

Btw, I didn't recommend it because of changset tracking, but rather if
we make significant changes to our dev infrastructure we might as well
build it on the right foundations and moving to SVN will be inevitable
at some point. I think it already provides enough value today to start
considering it.

Andi

-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Tuesday, May 29, 2007 9:39 PM
To: Andi Gutmans
Cc: Wez Furlong; Ilia Alshanetsky; Edin Kadribasic; PHP Internals List
Subject: Re: [PHP-DEV] better changeset tracking

I really don't think moving to subversion until they finish
the merge tracking code makes much sense. The only advantage
pre-1.5 is slightly better support for other tools that sit
on top of it, but even there it isn't a clear win. There are
changeset trackers for CVS as well that would be a lot easier
to add on to our current infrastructure than switching the
entire thing to svn first.

Once Subversion 1.5 comes out (which isn't that far off), the
landscape finally changes and assuming that it works, we'll
finally have a real technological incentive to move.

-Rasmus

Andi Gutmans wrote:

In general I think we should consider upgrading part of our
infrastructure. The only problem is that it takes a lot of time,
energy and devotion. And of course people need to be willing to get
used to the new way of doing things.
Foremost I think we could benefit from moving to SVN. We've
had very
good experiences with it and I think it fixes a lot of CVS
shortcomings.
The move would of course be quite an undertaking with years
and years
of history (and added/removed files).
The Zend Framework project is an example of an open-source project
where we have a more strict dev process. We open bugs for
everything
using JIRA (unfortunately Java-based but pretty powerful and
integrates nicely with SVN so that changesets are connected to the
bugs), it also allows us to easily see status of where we
are for the
release, and there are some nice perks like being able to
auto-generate a list of bug fixes for a given version
(http://framework.zend.com/issues/secure/Dashboard.jspa). There are
also quite a few other benefits but just by browsing around a db in
action some of those benefits should be visible.

Starting to look at this stuff would take a lot of effort
though and
not sure if there are enough able people willing to step up to the
plate. I think starting with a move to SVN would probably be best
because a lot of other apps integrate/depend on it.

Andi

-----Original Message-----
From: Wez Furlong [mailto:kingwez@gmail.com]
Sent: Monday, May 28, 2007 8:57 AM
To: Ilia Alshanetsky
Cc: Edin Kadribasic; PHP Internals List
Subject: [PHP-DEV] better changeset tracking

As a fellow busy person, I completely understand this situation.

I also recognize that we need to find a way to guarantee
that patches
don't slip through the cracks and don't get lost.

I think we could do with investing a little bit of time
into finding
a way to automatically review commits to see if they have
been merged
to
all relevant branches. For this to be viable, we should probably
adopt the practice of explicitly referencing a bug number in all
commits (could be enforced by the commit hook); we can
then analyze
the commit messages to make sure that commits referencing a
particular bug number have a corresponding set of commits in the
branches, and vice versa.

Once we have that data, we could have job that periodically
(daily) reviews the activity per bug report and sends an email
reminder about reports that have missing merge activity for longer
than a week.

--Wez.

PS: We could also consider posting links to commit URLs to the
associated bug report; this is a feature I really value in our
subversion/trac repositories at OmniTI.

Ilia, I would really like to know why you are not merging
patches to
head?
Unfortunately I don't have as much time to spend on PHP
as I'd like
and I focus my attention on the aspects of PHP I use and
can tests
using the dev environments I have. I do not have a ready PHP6
environment and do not have time to test thing with php6
code, with
which I do not have as much familiarity. Rather then
making commits
that may break the builds or spending hours resolving conflicts I
focus my attention on PHP5 where fixes and improvements
have tangible
benefits to users.

That said the commits are all public and if someone who is more
familiar with php6 code then I can merge them, it would be great.

Ilia Alshanetsky

--
To
unsubscribe,
visit: http://www.php.net/unsub.php

--
To
unsubscribe,
visit: http://www.php.net/unsub.php

Best regards,
Marcus