thinking about process, wondering if we can easily do better

Bill Barry after.fallout at gmail.com
Tue Jan 6 11:10:30 CST 2009


so... I was thinking about the way we are doing things in house here and 
I was wondering if there would be a better way to do this. Currently we 
have a process for getting our skin packages (zip files) for our 
application up to date in our working copies. That is to say currently 
we are versioning the zip files themselves. Currently we do the following:
"Programmer 1" - let's call her Sally

Sally would not consider herself a programmer; she would call herself a 
skin designer. Mostly her work is:
create a skin by manually creating .css files and html template files 
with the occasional jpg, etc
package up the skin into a zip file so that it can be used by the installer
make sure the skin installs (a special file called the manifest needs to 
be correct)
put the skin zip file in a special folder, possibly overwritting 
pre-existing skin
remove old skins
call hg addremove, hg commit, and hg push (possibly hg pull, hg update, 
and maybe hg merge somewhere)

on the other side:
"Programmer 2" - let's call him Bill
"Programmer 3" - let's call him Fred

Bill and Fred make actual code changes to the application and store the 
source for it in their repositories. All 3 pull and push to the same 
central repository location and see Sally's changes as opaque zip files. 
Every once in a while Bill or Fred need to see the actual change made in 
Sally's zip files; to do so they need to get both versions, extract them 
and then manually compare them.

I was wondering if we might possibly be able to use the encode/decode 
stuff somehow to store the unzipped skins instead of the zipped skins in 
the repository. Something like:
Sally puts Skin1.zip at:
/client1/Skin1.zip

Sally commits her change. The actual files inside Skin1.zip are 
extracted to:
/client1/Skin1/...
and Skin1.zip is not actually committed (it only appears to be on her 
machine via an encode and decode filter), instead the contents of the 
Skin1 directory are committed.

Fred and Bill both do not have the filters enabled. On our CI server 
though the filters are enabled so that it can take the skin files and 
use them as tests (and they are packaged into the installation file this 
way).

Am I thinking about this right? Is this something that can be done 
somehow (I can write code to do it, but if I have to do it mostly in 
python as part of hg I think the cost of the development outweighs the 
benefits; something small in C# or a simple batch script would be 
preferred, this will not run on a *nix box)?





More information about the Mercurial mailing list