Hi,
I do similar, with a tool named WinMerge, gotta love Open Source :).
http://winmerge.org/
Best,
--
Andries Seutens
http://andries.systray.be
Bill Karwin schreef:
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
Gecontroleerd op virussen door de JOJO Secure Gateway.
