SVN Restructure (thoughts and feelings)

[Jerome Gotangco]

> Now we move on to the next release and we have set ourselves much to do.
> However, before we start hacking the documents we need to do some restructure
> in SVN. Reason? Well, we need to accommodate GNOME and KDE and we would like
> to manage the translations in nn/ folders.

If I understand this right, because of the tool/renderer differences
with GNOME (Yelp) and KDE (konqueror?) our end product xml will have
different tags per desktop environment?

 
> I would like team input on restructure as much as possible. If we do it in
> trunk/ then everyone can see it without having to checkout a duplicate copy
> which will be in the branch. A payload of about 57MB with svn management
> files. It also means we don't have to track an additional copy and keep
> merging between them as we do the restructuring. If we do it in a branch
> people who want to have a say in the restructure will need to checkout the
> branch, as I said, this is +-57. Advantage of this method is that the trunk
> stays as it is now with make and build intact, but we will have to merge
> changes in trunk into the branch. Otherwise we will have to do it once all
> the restructure is over and that could be difficult depending on how far
> apart trunk and branch are at that point. Both methods have the same end
> result. With the branch method we just have to merge the branch into trunk
> once we are finished with the chaos.

I think for the sanity of the team and the translators, and to  chart
into new territory, the branch method sounds good to me.  We'll have
the end result anyway. If I got Sean's explanation correctly, the next
documentation release after 5.10 would be branched again?



-- 
Jerome S. Gotangco
GPG: A97B69A0 @ pgp.mit.edu
IRC: jsgotangco @ freenode #ubuntu, #ubuntu-doc, #ubuntu-devel, #ubuntu-ph

Ubuntu Local Community Philippine Team
http://www.ubuntu-ph.org