Hi All,

Just wanted to let you know of a change I am thinking of making to reduce the size of svn checkout and mainly to reduce the amount of time it takes to merge. So this is basically a heads up that I may try to do this soon and giving an opportunity if anyone has any concerns about the planned change.

As you probably know, we include about 30 decently good looking skins in the source code and release versions of mojoPortal, but we actually are storing and maintaining 2 copies of each skin in svn, the first set is under /Data/skins and the second is under /Data/Sites/1/skins. The first location is the catalog of skins, when a new site is created a new site specific folder is created under /Data/Sites/[SiteID] and the skins are copied there so that each site can have its own independent copy of skins and they are not shared across sites in a multi site installation. This is ideal because if you spend a lot of time and effort in making a custom skin you typically don't  want other sites in the same installation to be able to use it or have access to the files.

So until now we have had the extra set of skins already there for the first site in /Data/Sites/1/skins

Back when we only had a few skins the extra overhead of the duplicate files seemed not very important, but 30 skins is a lot of skins and each skin has a lot of files and images so its become more of a hassle maintaining changes in both copies of the skins.

So what I propose to do is delete from svn the /Data/Sites/1/skins folder and all of its contents and just copy the skins to that location when the first site is created from the setup page (as it does for additional sites).

Since skins do change over time and when updates are made to /Data/skins we may want to push those updates into each site. Currently only the site 1 is getting updates in that case during upgrades and any additional sites you currently would have to update the skins manually. In most cases production sites are probably using custom skins but for any sites that do use the standard skins it would be best to update them. Custom skins should be renamed to avoid being overwritten anyway, that is you shouldn't just customise an included skin, but copy it to a newe folder with a custom name then customise it that way it will never get overwritten by included skins. On development machines many are probably just using built in skins and we do always want the latest version.

So in addition to copying the skins to the site specific folder during site creation, I'm thinking it would be good to have a button in site settings that could be used to update built in skins for any site by copying them again from /Data/skins (where they are presumably most up to date) to the site specific skin folder. This button would only be available in Server Admin sites (the root site that manages the other sites) because I realize we may not want all the skins in child sites or let the child site admin have access to copy them.

For pre-compiled release packages I may continue to include the skins under /Data/Sites/1 to reduce potential support issues, but removing it from svn will make the size of the checkout a good deal smaller and make it take less time when merging the whole tree from a sandbox to trunk.

I can't really think of any big reasons not to make this change, but don't want it to come as a surprise to anyone working from svn when they do svn update and all those skin folders dissappear. They will come back after visiting the setup page.

Another reason for this is that sometime in the near future we may add even more skins. Some of our fixed width skins are very good looking but not really wide enough for today's big monitors, so I think they would be more appealing if I can make wider versions of some of the best looking ones. It will require resizing graphics and corresponding css changes so it will be not insignificant work to do this.

I will post again here once I actually do make this change to eliminate the duplicate storage of skins in svn (probably within the next few days). If anyone has any strong objection please say so now or forever hold your peace.

Best,

Joe