I apologize in advance for jumping into this thread so late (finally
trying to catch up on internals@).
FWIW, I'd also like to move to SVN, eventually (and inevitably (-: ).
I've opposed this move for php.net in the past, but only because the
proposals I was fighting were for a partial conv
Stefan Walk wrote:
At the moment, SVN is a pain in the ass when it comes to merging, but
they claim that it's fixed in 1.5...
svnmerge.py: http://www.orcaware.com/svn/wiki/Svnmerge.py
can help quite a lot as it maintains merges. And as it stores the merge
information in SVN properties I'm sur
On 5/31/07, Stefan Walk <[EMAIL PROTECTED]> wrote:
IMO, git is a choice worth thinking about for linux-only projects, but
if there are windows clients involved, it's not anymore (last time i
checked, it required cygwin).
I used it under cygwin and works well as far as I can tell (be sure to
use
IMO, git is a choice worth thinking about for linux-only projects, but
if there are windows clients involved, it's not anymore (last time i
checked, it required cygwin).
At the moment, SVN is a pain in the ass when it comes to merging, but
they claim that it's fixed in 1.5...
Regards,
Stefan
--
On 5/31/07, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> freedesktop has moved to GIT some time ago and for what I heard from
> the developers, it is a huge improvement in their development process.
> The only bad point (which exists with any other migratrion) is the
> time required to learn the
Pierre wrote:
> Hi,
>
> On 5/31/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
>
>> As we expect many more years for PHP we should make sure that the train
>> we're riding has momentum and can help us continue to scale our dev
>> process. I think SVN is the right train to hop onto.
>
> I would like
Hi,
On 5/31/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
As we expect many more years for PHP we should make sure that the train
we're riding has momentum and can help us continue to scale our dev
process. I think SVN is the right train to hop onto.
I would like to propose Git. I think it is m
Hi,
So I guess what we need is to figure out a bit what our current
development process is, what if it we actually want to keep and what we
are hoping to get in the future. Maybe we can brainstorm at php|vikinger
on this. One of the "processes" we have is that we have no formal
processes and
the right train to hop onto.
Andi
> -Original Message-
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 30, 2007 7:57 AM
> To: [EMAIL PROTECTED]
> Cc: PHP Internals List
> Subject: Re: [PHP-DEV] better changeset tracking
>
> Jani Taskinen wrot
Jani Taskinen wrote:
> On Wed, 2007-05-30 at 01:29 -0700, Rasmus Lerdorf wrote:
>> Well, the problem is that if the work involved to do this is in any way
>> CVS-specific, it will be throw-away work once we move away from CVS,
>> which is inevitable. What we don't know at this point is the lifespa
On Wed, 2007-05-30 at 01:29 -0700, Rasmus Lerdorf wrote:
> Well, the problem is that if the work involved to do this is in any way
> CVS-specific, it will be throw-away work once we move away from CVS,
> which is inevitable. What we don't know at this point is the lifespan
> of CVS. I'm unmotivat
Good luck forcing people developing PHP to do this or even agreeing
doing it. Laziness, do-what-I-need and chaos has been the driving force
of PHP development all the time. That works, why change it? ;)
But this is nice idea to add, having bug reports linked to cvs commits..
--Jani
On Tue, 2007
Wez Furlong wrote:
> As Rasmus said, it's a job for someone to sit down with a copy of the
> repository, cvs2svn, a lot of time, and a lot of patience, to make the
> migration work... but we're not stopping anyone from volunteering :)
I converted our company's CVS to SVN a while ago and might be w
On 5/30/07, Steph Fox <[EMAIL PROTECTED]> wrote:
Given that this entire thread came about because at least two of the core
team don't have time to deal with merging to HEAD, that doesn't seem very
likely. But you're right to put an end to quick-fix and possibly
cvs-specific solutions. Does svn ev
Rasmus,
We've kinda moved away from the problem in hand. Moving the entire
repository over to svn doesn't make it any easier to know when someone
commits something that should be merged and doesn't merge it. It also
doesn't do anything to resolve the relationship between PHP branch
releases and
Steph Fox wrote:
> Rasmus, hi,
>
> We've kinda moved away from the problem in hand. Moving the entire
> repository over to svn doesn't make it any easier to know when someone
> commits something that should be merged and doesn't merge it. It also
> doesn't do anything to resolve the relationship b
- Steph
- Original Message - From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Rasmus Lerdorf" <[EMAIL PROTECTED]>
Cc: "Wez Furlong" <[EMAIL PROTECTED]>; "Ilia Alshanetsky"
<[EMAIL PROTECTED]>; "Edin Kadribasic" <
oretical 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" <[EMAI
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 imh
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 tod
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 -
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
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 tha
f" <[EMAIL PROTECTED]>
> Cc: "Wez Furlong" <[EMAIL PROTECTED]>; "Ilia Alshanetsky"
> <[EMAIL PROTECTED]>; "Edin Kadribasic" <[EMAIL PROTECTED]>; "PHP Internals
> List"
> Sent: Wednesday, May 30, 2007 6:18 AM
> Subje
Hey Lukas,
Also keep in mind that there are plenty of subprojects under cvs.php.net.
These tend to be a lot simpler on the branching/merging side. So maybe
these are good testing grounds to get some of the infrastructure for karma
management in place. And then once we start feeling comfortable
din Kadribasic" <[EMAIL PROTECTED]>; "PHP Internals List"
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 performa
Andi Gutmans wrote:
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 wor
ay 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 on
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
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
On 5/29/07, Steph Fox <[EMAIL PROTECTED]> wrote:
This could work, except of course we don't have any such thing as 'a
maintenance ticket' or a way to set priority to 'merge'. It's kind of the
opposite way around to the way the PHP bug system works... and it
probably
would be a pain to have it a
On 5/29/07, Steph Fox <[EMAIL PROTECTED]> wrote:
This could work, except of course we don't have any such thing as 'a
maintenance ticket' or a way to set priority to 'merge'. It's kind of the
opposite way around to the way the PHP bug system works... and it probably
would be a pain to have it as
Hi Wez,
As you said, it's pretty straightforward to handle bugs this way, but
a pain to open a ticket for every little maintenance job. We solve
that problem by opening up a maintenance ticket per milestone (eg:
X.Y.Z release maintenance ticket) and use that as a catch all for
those misc commit
We use trac as an engineering ticketing system; we open tickets to
track things that need doing, be they bug fixes, enhancements or other
maintenance work.
We require that every commit to portions of the repos that contain
code reference a ticket number in trac, and reject commits that don't.
As
Hi Wez,
I think the key is in forcing every commit to reference a ticket; that
way you can't "lose" a changeset by forgetting to put a bug number in
there.
Going back on-list... It's a good idea in principle, but I can foresee some
problems with it.
Many (most?) of the unnumbered fixes Ilia
hi folks,
On Monday 28 May 2007 17:56:54 Wez Furlong wrote:
> 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
Wez Furlong wrote:
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.
Wouldnt we then also have to have some flag on the bug to make it clear
Sorry for my initial offlist reply. My evil gmail does not "reply-all"
by default :P
Here is an answer from Wez to my reply:
On 5/28/07, Pierre <[EMAIL PROTECTED]> wrote:
I'm all for this solution. I asked to do it a couple of years ago (and
a couple of times since). All commits besides CS or d
38 matches
Mail list logo
