All the Perl that's Practical to Extract and Report
use Perl Log In
jdavidb (1361)
(email not shown publicly)
http://voiceofjohn.blogspot.com/
J. David Blackstone has a Bachelor of Science in Computer Science and Engineering and nine years of experience at a wireless telecommunications company, where he learned Perl and never looked back. J. David has an advantage in that he works really hard, he has a passion for writing good software, and he knows many of the world's best Perl programmers.
Thinking of tracking build artifacts in git
My process and thinking are seriously slowed down by the long build times I'm dealing with. It's particularly frustrating when I realize I'm rebuilding the exact same stuff I built earlier just to check something out before reinserting the same changes with yet another twist.
In my process for using git, I specifically used
On the one hand, it would make life a lot simpler for me if the latest build on each branch were always available for me to revert to. On the other hand, it seems like I'll be storing a monstrous amount of redundant generated files. I guess I really don't care about storage space at this point. And maybe they can be vacuumed later. (In fact, they will be by virtue of the fact that all branches eventually get committed to CVS and deleted -- a garbage collection process after that would remove all the builds along the way.)
I guess I'm worried it would complicate my interaction with git. I'm used to just committing source to version control. Do I commit after a source change and then commit again after build, knowing that the source commit will have a previous build sitting there? Do I require my build to complete before I can ever commit? That would slow me down in a different way, I think.
Thinking out loud.
--Donald E. Knuth
Content-addressable (Score:1)
Note that git stores files based on their SHA-1 fingerprint. No matter how many copies of a particular file you have, and no matter when and how they were created, all of them together will only take up space once. So unless *all* of your artefacts change *all* the time, it should be fairly cheap to keep them around.
Re: (Score:2)
A lot of the objects are jars which contain timestamps. :(
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
Workflow (Score:1)
I think I would try keeping the artefacts in a different branch, putting a different
.gitignorein each branch. When you want to build, you check out the build branch, merge the source branch, build, and commit. To resume developing, you check out the source branch again.I haven’t thought through all the consequences, but I think that would be a fairly practicable way of keeping binaries around without mixing the build-related history and the source-edit-related history into a giant mishmash. It als
Re: (Score:2)
Thanks for the suggestion! I will add this to my musings over the next few days. :)
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers