On Tue, Aug 19, 2008 at 4:08 PM, Avery Pennarun <apenwarr@xxxxxxxxx> wrote: > Doing the 10-minute snapshot doesn't preclude the on-make snapshot. > Just commit at *both* times. But commiting "around the time there was > a successful build" is kind of pointless since you might change a file > two seconds later. (Or maybe only I'm that idiosyncratic. :)) I think I was unclear: the only point about the "roughly" was to emphasize that being dead-on 10 minutes line doesn't matter from the chronological aspect. Clearly you want to start the commit processes as soon as a successful compile you decide is worth keeping completes. (Actually, looking at the commit times on my cron-initiated commits the time is mostly 1 or 2 seconds past the 10 minute boundary already, so there's an already up to 2 seconds for my "detect new files" script to scan the directories.) > Shawn's GIT_INDEX_FILE script seems like a good place to start. If it > were me, I'd use *two* branches here: one for every time I build, and > one for the periodic commits. Then the build branch would always be > bisectable, and the periodic branch would always have up-to-date data. > Commits on the periodic branch would use *both* branch heads as > parents, so you'd be able to easily see and diff the full history. I think you mean 3 branches: successful compile, short term history (every 10 minutes) and long-term archival history (every hour). I already have the last two, although not in as optimal a manner as Shawn suggested, and wipe the short term history every week or so. Interesting idea. I'll ponder it. -- cheers, dave tweed__________________________ david.tweed@xxxxxxxxx Rm 124, School of Systems Engineering, University of Reading. "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
