1 mb is not big for git , 1 gb is. It's small. I version control blender files of 100-500mbs with ease . Git is always very fast.
I have used image files (PNG) for my project ChronosManager ,it fetches them together with the repo, they sit in their own image folder inside the repo folder that contains the code . I then open them with a path I get using filesystem currentdirectory method and then I navigate inside the folder searching using the name of folderminside the github-cache subfolder. You can find the code in that project. Don't know if that is the best way to do this , it works for me. I also check to make sure that images are not already loaded in the image because git may be fast but Pharo is very slow when loading PNG files. I load them once and save the image in them and I reload only if I change one of the PNGs. I have also created a mechanism to detect whether there is an update in the github repo and only then pull the git repo. It's a cheap hack where I put version info in the README which I access online and parse. I have created this way an auto update API. I could fine tune it to provide precise meta data of which png is updated and fetch only that but I have not felt the need so far to do this. On Sat, 15 Apr 2017 at 19:52, Peter Uhnak <i.uh...@gmail.com> wrote: > Hi, > > is there a common/best practice for using external files in tests? > > In my specific case I am interested in git-based projects, where I have a > big (~1MB) file stored in repository and I would like to use it in my tests. > > For GitFileTree project I could presumably use the following to access it: > > 'OP-XMI' asPackage mcPackage workingCopy repositoryGroup remotes first > directory / 'tests' / 'my-test-file.xmi' > > This will retrieve the MCPackage of the Package and then retireve where it > the repo is actually stored on the disk. > > Are there better ways to do this? Could something similar be done with > IceBerg? > > (p.s. in theory I could compile the entire file (e.g. 1MB) to a method, > but that is very ugly to me) > > Thanks, > Peter > >
