On Wed, Aug 7, 2013 at 11:23 PM, Themba Fletcher
<themba.fletc...@gmail.com> wrote:
> Hi all,
>
> I recently got a contract to rewrite a large (web) application. The
> intent is to transition, at a measured pace, from a large collection
> of hand-written, framework-free php files to a structured setup with a
> nice MVC framework, etc.
>
> So far so good. I've got all the original source in a fossil repo and
> it has a pretty rich history as I've been maintaining this system for
> the last year or so.
>
> Moving this to the framework I've chosen will involve, up front,
> moving every single one of the exisiting source files to a new
> location deeper in the project hierarchy. The files will then be
> slowly replaced as their functionality is added to the new system in
> the appropriate place.
>
> I'd love to be able to do this project with hotfixes continuing on
> trunk as the deployed version evolves and having all of the
> restructuring take place on a super massive "v2" branch, but I'm
> anticipating a few problems:
>
> * Merging updates from trunk to v2 -- cherrypick isn't going to work
> very well when the names don't match anymore, is it?
>
> * What should I expect after I've deleted a file on v2 (having
> replaced its functionality) and then merge back some updates from
> trunk containing a change to that file? Just a plain old merge
> conflict or should I expect and watch for the file to reappear on the
> branch after being previously deleted?
>
> * Anything else you can foresee?
Why cherrypick? The simplest workflow here is, as you mention, develop
new stuff in a v2 branch and fix bugs in trunk. The key secret here is
the mantra: merge soon, merge often.
I must admint that I haven't used Fossil long enough but what I would
expect from Fossil is to give me a hard time the first time I merge from
v2 to trunk, and straightforward merges the following times. Take the
following example:
A B
trunk --o--o---o-------o
\ \
v2 ---o---o--o--o--o--o--o---o--o--o--o
C D E F
Assume that D is the first merge and is the hell of a merge. The next
merge (which joins B and E) will have A as the common ancestor. So,
unless you hit a bug in Fossil, merge F is only about incorporating the
changes between A and B into the v2 branch. Merge F then makes B the
common ancestor for the next merge.
The advantage here is that, when v2 is ready for primetime, you just
have to merge v2 into trunk and it should be a trivial merge too.
In short, just follow these rules:
- Don't cherrypick.
- Always merge trunk into v2. That is: checkout v2 and, from there,
merge trunk. This way the merge is committed as part of the v2
branch. When v2 is finished, proceed inversely.
- Don't let the trunk with a leaf for too long. Remember: merge soon,
merge often. The v2 branch should host most of the development
activity, so merges will not be so abundant.
- Personal advice, use a graphical merge tool (e.g. kdiff3). Fossil
can be configured to resolve conflicts with them; otherwise, I
wouldn't even be writing this.
> Has anyone out there tried a complete project restructuring on a
> branch with any success, or is the default workflow to just spin up
> another repo and synchronize changes by hand? Any other thoughts or
> input?
I have successfully performed some heavy refactorings with this workflow
a couple of times now, but with Mercurial. As I said, I would expect
Fossil to work the same in this workflow because it is a very simple
one: no criss-cross merges, no cherrypicking and the resulting history
is beautifully clean.
I hope it helps. Best regards.
--
Isaac Jurado
"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
