Fix puli/issues#178

The build cli command do two things: clear the repository and rebuild it. To clean the repository, the manager call the method clear of the configured repository (in our case FilsystemRepository).

In the FilesystemRepository, clear calls removeResource on all the resources in the repository. When using the FilesystemRepository with symlinks, it means removeResource is called on all the links present in .puli/path-mappings. However, removeResource is, for the moment, always recursive: all the children of the given path will be removed before trying to remove the path itself.

When trying to remove a directory link, removeResource list all its children to remove them: however, the children of a directory link are the real children in the filesystem. So the real files are removed.

This PR fixes this.

Following the OptimizedPathMapping repository (puli/repository#27), I implemented a development version of this repository, as proposed by @webmozart in puli/issues#80. This pull-request is a place to debate over the code.

I did three main things:

1. Create the repository

https://github.com/tgalopin/repository/blob/dev-path-mapping/src/PathMappingRepository.php

The repository follows these rules:

• When a resource is added, the association repositoryPath => filesystemPath is stored in the KeyValueStore, and the parents of the repositoryPath are created as virtual resources ;
• When a resource is fetched (using get() or other methods), its repositoryPath is resolved to a filesystemPath: the repository find the list of virtual resources matching the searched resource repositoryPath and try to find a real directory / file corresponding to the resource in each of these virtual resources ;

This technique is much slower than the optimized version (obviously :) ) but it's a really useful tool for development as the structure inside virtual resources can change without having to "recreate" the puli repository.

2. Add a build structure system in tests

https://github.com/tgalopin/repository/blob/dev-path-mapping/tests/AbstractRepositoryTest.php#L62

This repository was not possible to test using the exact same tests as before as when we are requesting a resources, it can be either a virtual or a real one, and tests have to check for both at the same time.

I had to create a real valid structure on filesystem according to the tests: I couldn't without altering a bit the existing tests.

I added a buildStructure method, called on each built resources (for instance https://github.com/tgalopin/repository/blob/dev-path-mapping/tests/AbstractRepositoryTest.php#L102) that by default return the root resource to be compatible with other repositories tests.

But in the PathMappingRepository tests, this method create the structure (https://github.com/tgalopin/repository/blob/dev-path-mapping/tests/PathMappingRepositoryTest.php#L113) for tests to work properly.

3. Create the specific tests for the PathMappingRepository

Once the built structure ready, I fixed the repository to pass the tests (https://github.com/tgalopin/repository/blob/dev-path-mapping/tests/PathMappingRepositoryTest.php).

I'm very open to modifications, expecially on how find() and contains() work as I'm not sure it's the best algorithm possible.

This PR shows a problem with resolving children filesystempaths.

PathMappingRepository.php Line 226
$filesystemPath = substr_replace($path, rtrim($filesystemBasePath, '/').'/', 0, strlen($basePath));

If you use find to resolve the children, the filesystemPath contains after this line potential '//' in the path and this doesn't match than in the "getFilesystemPathChildren" method and so no correct repository path is set.

Potential Bugfix is to replace all '//' with '/' in the filesystemPath

Fix https://github.com/puli/issues/issues/90.

This PR aims to introduce two concepts:

• the ChangeStream that log every resource modification on all the repositories (it's shared between repositories)
• the ResourceStack which is a ResourceCollection representing all the versions of a resource over the time

The ChangeStream, when provided in a repository, store as a simple array a representation of all the resources given to it by the repositories. Using simple arrays let PHP remove old resources objects.

If you want to retreive previous versions of a resource, you can access a classical resource and use the method getStack() on it:

$repository->get('/tgalopin/foo/bar')->getStack();

Internally, this method calls the ChangeStream to build a ResourceStack for the given resource path (here /tgalopin/foo/bar).

This PR is a work in progress but the main last thing to do is testing.

On Windows, symlink does not work like on Unix, the OS think it is a real file like another. So for time operations, it only see changes on the symlink file and not the original one. That mean fileXtime functions get info about the symlink file too.

So if you make some changes in the original file, Puli will not seen anything if this file is register in the repository as a symlink. It work as espected for files in a symlink directory.

Fix https://github.com/puli/issues/issues/125.

As suggested by @webmozart, it should be possible to access the children of a directory link seemlessly, ie something like:

$repo = new InMemoryRepository();
$repo->add('/dir', new DirectoryResource('/some/directory'));
$repo->add('/dir-link', new LinkResource('/dir'));
$repo->get('/dir-link/file');

This PR aims to implement this.

As explained in puli/issues#80, I implemented an optmized version of the PathMappingRepository. This pull-request is not ready for the moment, please do not merge it now. It's just a place for dicussion about the code.

I want to explain what I did and what I plan to do to discuss, especially with @webmozart :) .

1. Create the repository ✓

https://github.com/puli/repository/compare/1.0...tgalopin:path-mapping?diff=unified&name=path-mapping#diff-55bbc453f8c7d643ba2cd09cc280c00f

As discussed with @webmozart, optimized and not optimized versions of the PathMappingRepository are completely different in code, it makes sense to separate them. I created the optimized version only for the moment and I'll open another pull-request for the classical one.

2. Create a GenericFilesystemResource ✓

https://github.com/puli/repository/compare/1.0...tgalopin:path-mapping?diff=unified&name=path-mapping#diff-2ba3bf2e348a04a316173aba204de2d9

It's the best solution I found to store a virtual directory in the repository. Here is the problem:

• I want to store only FilesystemResource instances in the repository ;
• However, when someone add the path /webmozart/puli/file1, the paths /webmozart and /webmozart/puli should be created if they does not exist. But they don't have to represent a real file on the system ;

So I created this class to represent a generic, virtual filesystem resource usable in the repository while not having any real file / directory behind it. Perhaps are there better ways or just a better name for this class, please tell me if you think of something :) .

3. Externalize test resources creation in order to be able to override it ✓

https://github.com/puli/repository/compare/1.0...tgalopin:path-mapping?diff=unified&name=path-mapping#diff-59ad75cfaee83a692af80d3634224473

As my repository only handle FilesystemResource instances, I needed to create specific testing objects. I had to externalize this creation, so I edited the abstract tests in order to do so.

4. Add specific tests for the optimized version ✓

https://github.com/puli/repository/blob/a25287982a5d2c64c0ed507532110af89bd614b8/tests/OptimizedPathMappingRepositoryTest.php

Test that the adding of a single directory does add all the children of this directory in the right place.

Do you think of other specific test I could have forgotten?

Normalize path to fix windows backslash issues.

Tests are still red... This only fixes a general backslash bug, that prevents me from using puli on windows.

Fix https://github.com/puli/issues/issues/107.

This is a work in progress.

Small question: what happen for a LinkResource in the FilesystemRepository? How do we store it? Do we create a symlink?

Pull request for https://github.com/puli/issues/issues/105

A question I'm asking myself is what to do if a resource is not found for deletion. For the moment, if the remove() method does not found any path to remove, it returns 0, which seems fine. However, as it's a specific context (PathMapping repository does only supports remove on mapped directories), we might want to throw a BadMethodException on invalid remove call.

What do you think?

The beta6 version of the PathMappingRepository was a beginning, but it's clear now that I didn't thought it well enough to take all the use-cases into account.

This PR aim to introduce a new, simpler and more efficient version of the PathMappingRepository to fix the issues https://github.com/puli/repository/pull/40 and https://github.com/puli/repository/pull/39. Once this PR will be ready, I'll also work on the windows problems (https://github.com/puli/issues/issues/102), the link resources (https://github.com/puli/issues/issues/107) and the versionning (https://github.com/puli/issues/issues/90).