[Server-devel] [XSCE] Dealing with huge xsce repo size

[George Hunt]

There's a political reason for the size of the repo.

In my discussions with Daniel Drake at the last SF summit, we discussed the
relationship between the work of XSCE and his finished 0.7 school server.
 The XSCE repo started from a clone of 0.7, which itself appears to trace
back all the way to the beginning of Martin's work on the server.

Daniel asked me to "pretty up" the XSCE commits, and collect them into
functional chunks, and submit them to Martin for review, as he had done
going from 0.6 to 0.7.  When I tried to learn, and use the git rebase
command, my lack of skill, and patience, came in the way of that objective.
 The number merge conflicts, and the need for merge-by-hand, seemed to me
to be just too likely to introduce errors, and the need for additional
debugging cycles.

At this point, the code base has diverged so much, I'm not willing to
rework the history as we discussed almost a year ago.

The reason to go slow in trimming down the size of the repo, from my point
of view, is that I'm not sure XSCE has replicated all the essential
functions of 0.7, particularly in the area of activation, lease management,
and anti-theft. These are essential features for large deployments.  Until
we learn about, and learn to test, in this area, we might want to keep
around the original functioning code.

George


On Sun, Sep 8, 2013 at 12:37 AM, Anish Mangal <anish at activitycentral.com>wrote:

> Hi,
>
> This is perhaps a very contentious topic, so I want to discuss with
> extreme caution :-)
>
> The size of the git repository for xsce is > 70MB
> The actual size of the files is < 3MB
>
> Now, I don't want to hurt anyone's sensibilities AT ALL here, but I feel
> 70MB is quite a huge size for a repo containing code worth only 3 MB. I
> also feel it's a hindrance to keep code development nimble, making it
> unnecessarily difficult for users to download large repos. (Remember, if
> you're cloning a git repo, and you lose connectivity, you have to start
> over).
>
> Are there any thoughts we could improve the situation? Should it be
> improved?
>
> Best,
> Anish
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/server-devel/attachments/20130908/44f6fc0f/attachment-0001.html>