[texworks] Another TeXworks mac build (with a buildsystem!)

[Stefan Löffler]

Hi,

On 2011-05-16 01:10, Charlie Sharpsteen wrote:
> On Sun, May 15, 2011 at 1:17 AM, Stefan Löffler <st.loeffler at gmail.com> wrote:
>> Great! Maybe you could even do that before all the packaging-related
>> questions are resolved, so people can build their own 0.4 stable release?
>> But then again, there is a new one (0.4.1) coming up soon (hopefully), so
>> maybe there isn't too much sense into building oneselve an 0.4.0 now...
> There is one dilemma that I did not forsee as this is the first time I
> have published a repository that was cloned using git-svn.  The
> problem is that when I started this project, I was only interested in
> the TeXworks trunk, so I only cloned the trunk:
>
>     git svn clone http://texworks.googlecode.com/svn/trunk/
>
> If I now clone the rest of the SVN tree from:
>
>     http://texworks.googlecode.com/svn
>
> Git sees it as a completely separate repository since there is a
> different "root path". So, what I have published on GitHub is not a
> suitable mirror of the SVN repository for someone who is interested in
> working with branches or tags.
>
> There are two choices:
>
>     1. Use `git rebase` to graft the release-0.4.0 tag onto my clone
> of the trunk. This will create a Git branch that people can pull and
> build from, but the result will still be unsatisfactory for anyone
> looking for a true mirror of the SVN repo.
>
>     2. Re-clone the SVN repo using `svn` as the root path instead of
> `svn/trunk`---this will create a full mirror. Then I would move my
> master branch over to this new clone. The problem with this choice is
> that anyone who has already cloned my git repository would have to
> deal with an "upstream rebase" (this means the history of a repository
> you pulled from got re-written). This means that they have to stash
> any changes that I haven't accepted in a pull request and then
> re-synch with my master branch:

First, a few observations from my side:
 * Pulling in 0.4.0 strikes me as a short-term solution. 0.4.1 is in the
making, and hopefully many more releases will follow. Of course, the
CMake files might be pulled into the upstream repo, but for now this has
not been decided, so it's probably safer to draft a solution that
doesn't depend on that.

 * There are several directories in the root path that are probably not
needed, like manual/, website/, or wiki/ (note that the manual is
included in the releases). branches/ right now only contains copies of
the 0.2 and 0.4 stable series and is used primarily for cherry-picking,
but of course might be used for testing "release candidates" in the
future (other than that, branches would probably be only of interest to
some few developers who could merge your cmake-only changes). So cloning
the whole repo seems like overkill to me. From my POV, all that's needed
right now is really trunk/ and tags/ (but, according to the observation
above, with the possibility to expand this list).

So, it would seem to me that making a cut now is probably the best
option. I don't know how many people (apart from me) actually have
changes to the code they need to rebase - please speak up now ;) - but I
guess the number is small.

HTH
Stefan