Opened 13 years ago

Closed 13 years ago

Last modified 21 months ago

#7618 closed enhancement (fixed)

Remove all files in the /engine-data folder

Reported by: bluegr Owned by: sev-
Priority: normal Component: --Other--
Keywords: Cc:


The extra files needed by some games (e.g. kyra.dat, lure.dat etc) used to be in the /engine-data folder. Now, these files have been moved to the /scummvm/trunk/dists/engine-data folder instead, but all the old files are still left in the /engine-data folder, which serves no real purpose now other than to confuse people and lead to situations like this:

Since the files in the /engine-data folder are now obsolete and old, it would be good if that directory were removed altogether, or alternatively only the files in it could be deleted, and a README file placed which would link to the correct directory

Ticket imported from: #1878427. Ticket imported from: feature-requests/434.

Change History (11)

comment:1 by jvprat, 13 years ago

I don't think they should be completely removed, like older code releases aren't removed from svn, so anyone can find all the needed code and data to run any previous release.

Well, I've just had a look and it looks like there's just a 0.10 tag and trunk. I thought engine-data was tagged for several releases before. The trunk is now living inside scummvm code so it can be removed safely. The question would be what to do with older versions. One option is to recover older data files and copy them into their corresponding code branch, to put them in the same condition as trunk. Any objection on this?

Anyway what should be removed for sure are references to those paths in the documentation, and maybe clarify it to say that you no longer need to copy those files to your game directory (maybe it isn't true for some ports?).

comment:2 by fingolfin, 13 years ago

Owner: set to sev-

comment:3 by fingolfin, 13 years ago

agreed, jvprat: just removing this module completely is certainly wrong, although emptying the "trunk" dir would be fine. Feel free to go ahead with that.

As for older releases: We only introduced that dir at a certain point, it's possible that this was after 0.9.0, not sure. Of course if we can manage to get older engine data sets together and put them in corresponding release dirs, that would be nice. But that's not very important.

Adjusting the docs: Well, it's somewhat port specific, I guess. It may be necessary to talk to porters about specific sections, I guess. but in any case, references to the engine-data repository should be removed everywhere.

Eugene, anything to add?

comment:4 by jvprat, 13 years ago

I've been preparing the commit locally. Here are a few questions:

* Should /engine-data completely be removed or put a little readme inside to guide the lost users? I've prepared this: "The engine-data files now live inside ScummVM's code directory and are tagged whith each release. You can find them in the following places:

- For trunk: /scummvm/trunk/dists/engine-data/ - For previous releases: /scummvm/tags/release-X-Y-Z/dists/engine-data/"

* What's the best place to put the data files for older releases? The release tags, the branches or both? Putting them inside the release tag will be coherent with the last release for future reference, but it would be different than the contents of the released tarballs.

* For reference here's the list of the releases I've prepared with the origin of their engine-data files, based on date of release and links from the download page:

- From /engine-data/tags/release-0-10-0: scummvm/tags/release-0-10-0a/dists/engine-data scummvm/tags/release-0-10-0/dists/engine-data

- From /engine-data/trunk r22700 scummvm/tags/release-0-9-1/dists/engine-data scummvm/tags/release-0-9-0/dists/engine-data

- From /engine-data/trunk r20454: scummvm/tags/release-0-8-2/dists/engine-data scummvm/tags/release-0-8-1/dists/engine-data

- From /engine-data/trunk r3393: scummvm/tags/release-0-8-0/dists/engine-data

* It looks like the only previous releases that needed data files were 0.7.0 and 0.7.1, which just had queen and sky, and their data files didn't change in next releases. Should those releases also be filled with the same files of the 0.8.0 release for completeness?

Thanks for your comments!

comment:5 by sev-, 13 years ago

o Yes, we definitely should kill files in engine-data/trunk o Yes, it is a good idea to leave README file there o This is an excellent idea to restore old versions of the files. The place to put them is tags directory o And yes, it would be better to keep separate directory even for files which did not change between the releases

comment:6 by jvprat, 13 years ago

Resolution: fixed
Status: newclosed

comment:7 by jvprat, 13 years ago


comment:8 by fingolfin, 13 years ago

Erm, sorry, but I think this was a bad move.

jvprat, you just modified the release tags of *scummvm*. As a result, the (still existing) .tar.gz files for each of these release are now out of sync with the release tags. Bad!

I really think the correct way would have been to add corresponding "release tags" to the "engine-data" module. So e.g. the content of scummvm/tags/release-0-8-2/dists/engine-data should really be in engine-data/tags/release-0-8-2/ and the old "scummvm" release tags should be restored.

comment:9 by jvprat, 13 years ago

Ok, I'm sorry. I'm going to revert it now.

I expressed my concern about the consistency of the released tarballs and I tried to explain in detail the destination of the commit, both in the contents of the readme and in the list of directories, but it seems there's been some misunderstanding. Maybe I've been too fast. Sorry again.

comment:10 by fingolfin, 13 years ago

Jordi, no worries -- you were quite clear in what you said about your movement plans. We just missed that detail (reading what we thought should be there, not what was actually there ;-). A typical communication problem, but a very harmless one. Thanks for fixing this so quickly, and thanks once more for doing the work on this FR!

comment:11 by digitall, 21 months ago

Component: --Other--
Note: See TracTickets for help on using tickets.