I use also tools which are able to do such things...
UltraCompare is my choice.
I think we should also write this "best practice" into the document.
Just to mention: Even if the things are clear to me, I asked this questions
because documentation did not make this clear enough ;-)
Greetings
Thomas
I18N Team Leader
----- Original Message -----
From: "Bill Karwin" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, July 18, 2007 12:20 AM
Subject: RE: [fw-general] Re: Lifecycle Handling
Yes, the best working practice is to maintain two svn working copies.
One for trunk, and one for the branch (remember to "svn update" in both
trees regularly!)
Here's a recommendation: I use a tool for comparing two directory
trees, called zsCompare. It allows me to compare full directories, and
see which files are different. Then I can open an individual file in
both trees to compare side by side. Then I can merge lines of code from
one tree to the other on a case-by-case basis.
http://www.zizasoft.com/products/zsCompare/index.shtml
The Lite version costs only US$35 for a single license. I think it's
perfect for cases like this where you are comparing and merging bits
between two similar trees of files.
I started using zsCompare when I was programming in Java, because the
tool can compare collections of files even inside .zip or .jar archives!
It saved me a lot of time.
Of course other tools exist that can be used in a similar way, but
zsCompare works well for me.
Regards,
Bill Karwin
-----Original Message-----
From: Thomas Weidner [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 17, 2007 3:00 PM
To: Bill Karwin; [email protected]
Subject: Re: [fw-general] Re: Lifecycle Handling
Hy,
which means that core-contributors have to have two released
on their workstations.
The trunk for new features and the branch for maintenance releases.
That's what I asked for and noone was able to definitly say yes or no.
I expect most people would not be very amused if I fix bugs
only for 1.1
(trunk) instead of 1.0.x (branch) ;-)
Greetings
Thomas
I18N Team Leader
----- Original Message -----
From: "Bill Karwin" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, July 17, 2007 11:15 PM
Subject: RE: [fw-general] Re: Lifecycle Handling
> -----Original Message-----
> From: Thomas Weidner [mailto:[EMAIL PROTECTED]
>
> For example Zend_Date....
> I've integrated new features (array access).
> But when there is a new bug I have to integrate it in trunk
> (where the new feature resists) and in maintenance.
> Otherwise the maintenance branch would also have the new
> feature integrated which is not allowed.
This means there are a few choices:
(a) Implement the same bug fix in a different way, to work
with the code
in the branch. But depending on the nature of the bug, this
may be too
much work.
(b) Implement the bug fix in both trunk and branch,
implemented in a way
that doesn't rely on the new features. Sometimes this is
possible, but
sometimes it's not possible or it's too much work.
(c) Fix the bug in the trunk but don't fix it in the branch.
Users must
wait until 1.1.0 to get some bug fixes.
I think all cases will fit into the three choices above. :-)
Regards,
Bill Karwin
