|can no longer guess file system locations from user file locations [message #924827]
||Thu, 27 September 2012 06:48
| Rafael Chaves
Registered: July 2009
In dev.cloudfier.com I have a hack for implementing project-wide builds:|
1) I run a server side-by-side with Orion (could be merged in one, but that should not matter), so I can access the project contents
2) Implement a validator service that will pass the location of the file being validated to my server (instead of the contents)
3) The server will then construct a file system location by appending the location to the workspace location: I get to the relevant user file, can walk up to the containing dir for the project location, etc, so I can build the entire project.
However, 1.0M2 breaks this hack, and I can't at this point move to this version: the locations representing user files no longer expose the hashes used in the file system storage, so it is no longer possible to map the location a validator gets from Orion to a file system location.
Granted, I was relying on unspecified behavior. But at the same time I am just trying to implement functionality Orion should ideally be providing out of the box.
So, any ideas of how to get out of this situation? Things I thought:
1) Orion file system locations preserved user-chosen names (I guess the goal of the hashes here is to avoid file system limitations for file names?)
2) Orion exposes both user-facing and internal locations (ugly, now there would be two locations for everything)
3) Orion provides a server setting that allows reverting locations to be hashed as pre-M2
4) I implement my own file service that saves data in my own server (which would be unfortunate, as I'd rather not be in the business of file storage - and I guess the user would lose Git support for his files)
5) Orion provides support for project-wide validation (say, the validator is given a parameter that allows it to browse the tree and fetch file contents).
[Updated on: Thu, 27 September 2012 07:59]
Report message to a moderator
Powered by FUDForum
. Page generated in 0.01997 seconds