I'd say that his problem is to use a DVCS with lots of data in binary files (game assets). He's bound to run into trouble even with mercurial.
The idea of keeping everything is seducing and works extremely well for source code because it's small and is easily "deltaized" and compressed, but it's just not practical for large amounts of binary data. Where I work (on some big open world game), we don't even store very revision of binary files, only a dozen or so, and the older ones are discarded. Our VCS is perforce, it allows to setup this kind of rule per file type so we can say things such as "only keep 10 revisions of png files". The metadata for all revisions are kept, but the data itself is thrown away. On Tue, Mar 10, 2015 at 9:52 PM Ron W <ronw.m...@gmail.com> wrote: > On Tue, Mar 10, 2015 at 4:37 PM, jungle Boogie <jungleboog...@gmail.com> > wrote: > >> On 10 March 2015 at 12:15, Ron W <ronw.m...@gmail.com> wrote: >> > > Seems to me that he doesn't realize that Fossil separates the repository >> > from the "working copy". He's expecting "fossil clone" to work like Git >> or >> > Hg where the working copy is automatically created. >> >> Yes, exactly. It's a couple extra steps to open it up. If he's willing >> to leave Fossil because of that, oh well! > > > I suspect the main reason was the problem with large files, whatever his > threshold for large is. Not a limit I've run into, yet. > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
