[Lunar-commits] r17689 - moonbase/trunk/zbeta/e_modules-cvs

[Chad Kittel]

Author: v3rt1g0
Date: 2005-12-17 22:16:37 +0000 (Sat, 17 Dec 2005)
New Revision: 17689

Added:
   moonbase/trunk/zbeta/e_modules-cvs/POST_BUILD
Log:
  Misc Tweak: e_modules-cvs (beta)

  * Due to the way we update cvs modules in lunar, the source
    location change I made earlier will cause some weird results
    for our users.  Adding a temp "workaround" until I guess that
    it is no longer needed.  See the message in the POST_BUILD file
    for more details.


Added: moonbase/trunk/zbeta/e_modules-cvs/POST_BUILD
===================================================================
--- moonbase/trunk/zbeta/e_modules-cvs/POST_BUILD	2005-12-17 17:45:44 UTC (rev 17688)
+++ moonbase/trunk/zbeta/e_modules-cvs/POST_BUILD	2005-12-17 22:16:37 UTC (rev 17689)
@@ -0,0 +1,18 @@
+# Due to a change of location of this module on the sf.net e17 CVS
+# server, anyone who had a copy of e_modules-cvs-beta.tar.bz2 in the
+# lunar source spool prior to the location change will have a 
+# "incorrect" source tree in their source cache.  Lunar will attempt to
+# "cvs up" from the old location (which actually still exists on the 
+# sf.net servers) and the user will never be getting new updates to this
+# module.  The only way updates would come though is if the .tar.bz2
+# file was from the new tree or the file didn't exsit (fresh co).  As a
+# work-around to this change (and after chatting about it with tchan),
+# we figured a semi-resonable soultion would be (temporarly) adding code
+# in this POST_BUILD file that removed the .tar.bz2 file from lunar's
+# source spool.  This means that people who have a "bad" .tar.bz2 file
+# will have a "bad" .tar.bz2 file for one more update and then after
+# that it will be all fresh checkouts.  The source tree is small enough
+# that an "cvs up" vs "cvs co" might not even take that much longer.
+# Again, this is a temporary situation only, when I feel it's "safe," 
+# I'll remove this file.
+rm -f $SOURCE_CACHE/$SOURCE