Christian Ohm schreef: > On Sunday, 5 October 2008 at 1:50, bugs buggy wrote: >> With the upcoming release of the FMV patch in trunk, *before* we add the >> fmvs into the repo, I would like to confirm the data structure. > > Question: Why do you want to add those to SVN? I can understand the rest of > the > data (well, perhaps not the music, but that is not that large), but the FVMs? > Those are large, won't really be modified and are not necessary for the game.
I don't like the idea of adding the videos to our repo either... >> trunk/data (only pumpkin official stuff, + derivatives of their work?) >> trunk/code or trunk/source >> trunk/FMVs (since it is optional?) > > And even separated from the rest? What's the difference to just having a > separate archive then? > > And when you don't have the movies in SVN, what exactly are the benefits of > separating source and data? > > Packaging? Were there any complaints about that? The Debian packaging system > easily allows the creation of separate packages from one source archive, and > I'd imagine any other deserving that name does as well. Packaging by external parties is IMO a non-issue. If they have *real* issues with whatever directory layout we provide then *they* should bring that up on *this* mailing list. Considering that no such thing has been brought to this list I'd consider packaging a void argument. > Redownloading changed textures? How often are those changed? I think Buginator > complained about the bandwidth required comparing revisions before and after a > big change. AFAIK that is the only reason. > But if the src and data are separated, that won't magically make those old big > changes go away, and introduce another one. No, it will definitely not solve the issues for, e.g., the "PNG shrinkage" revisions. It will indeed introduce a new problem (of larger scale) with the revision that performs the directory layout migration as boundary. The only advantage I can see is that, after said layout migration, huge changes to the data (such as aforementioned "PNG shrinkage") will have a much less significant impact on the code when you need to jump between revisions. When put in that light changing the directory layout doesn't sound very appealing to me anymore. In fact it sounds like the wrong solution to this problem to me. IMO a better solution would be to require changes of large amounts of binary data to go through this mailing list first. Here "changes" would be defined as having "svn status" give one of these values in the first column: "A", "M" or "R". Whatever "large" means would have to be decided upon. > And this problem seems easier solved by having the complete SVN history > locally, with a tool like git-svn, hgsvn (for Mercurial) or SVK (I guess > there > are more, those are just the ones I know of). Yup, especially when using the history of the repo heavily I prefer a distributed solution (I'm mainly using git-svn myself). > Those were the reasons listed in this thread, and both don't seem very > convincing to me. Are there other advantages I have missed? The only one I know of is faster history "browsing" in light of large changes. -- Giel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
