Re: Proposal to refactor the CSS test repo

On Apr 24, 2014, at 12:01 PM, Rebecca Hauck <rhauck@adobe.com> wrote:

> […]
>>>> 
>>>> I have no issue with this plan, but do note than many tests are linked to more than one spec and I expect that to get more common as specs evolve. So while we can adopt a simple convention, like put the test in the directory for the first linked spec, people will have to be aware that the files under a single directory are not the exhaustive list of the tests for that spec. Gathering and copying all the tests for a single spec into a single package is what the build scripts do.
>>> 
>>> 
>>> Yes, I’d planned on going with the first spec link for the actually copy, but Tobie’s suggestion for using symlinks may work well for this scenario. AFAIK, github treats symlinks just as the file system does. Of course that means that if the original file is deleted, the onus is on the deleter to remove the symlink or they’ll be left dangling.  This is a minor issue that can be automated though.   What are the implications of this approach on the build scripts and Shepherd?
>> 
>> Symlinks would just appear to be additional copies of the files, both Shepherd and the build scripts already deal with that just fine (although I have to verify how mercurial's internal APIs treat them for some of Shepherd's code). For that matter, making copies of the tests rather than symlinks would also be fine with the tools, for example, we already do that with most of the support files.
> 
> 
> I don’t think we want to make copies for obvious reasons when tests require updates.

Agreed, I'm not advocating it, just pointing out that the tools deal with it.

> 
>> 
>> Both mercurial and git handle symlinks, so long as the hg-git tool deals with them that should be ok, my main concern with symlinks is that I don't believe either mercurial or git handle them properly on Windows systems...
> 
> 
> Crap. I’ll dust off my VM and test this out to see what happens.

Yeah, at least we're not stuck with 8.3 filenames...

> 
>> 
>> I'm also concerned with the general usability issues with symlinks, I'm not sure most test developers will understand, and deal with all the consequences of working with linked files.
> 
> 
> Are you talking just about removing files and being unaware that they have references to them? I think we can handle that pretty easily on our end with a couple lines added to the script that sniffs incoming commits.  What are your other concerns?

file renames, file moves, and thinking you're editing a file in one place and that it's not affecting the others (although having files with the same names but different contents is frowned upon anyway).

> 
>> 
>>> 
>>>> 
>>>> When you move the tests, you'll also need to be really careful of filename collisions. I don't want to see tests get lost during the move.
>>> 
>>> 
>>> Sure.  What do you suggest for making them unique? 
>> 
>> Just follow the current naming conventions. But also be really careful about updating reference links when files get renamed, this is usually one of the biggest causes of breakage.
> 
> 
> Can you elaborate on what the current naming conventions are? I’m not aware of what they are for this scenario. For example, what do I do when I encounter two files named css-foo-001.html?

If the files are indeed different, and both valid tests, change one of them to css-foo-002.html, or make the name component more significant: css-foo-var-001.html


> 
> […]
> 
>> 
>>>> 
>>>> The updates for Shepherd are small and in one class, the build scripts will need the most work. I'm heading out for a long weekend tomorrow but should have time to update these in the second half of next week or so.
>>>> 
>>>> When we're ready, I propose that I make a fork of the repo on our server, then you can move all the files around and push to the fork. This will give me a chance to test all of our tooling against the new repository structure before we push it to the main repo. Once it's landed I'll delete the fork.
>>> 
>>> 
>>> Can I just get started on my local fork in a branch? I’ll probably start this early next week.
>> 
>> Shepherd looks at all branches, so working in a branch wont isolate your work from Shepherd if it gets pushed to the server.
>> 
>> Just create a new local clone and do the re-org in that clone. When you're done let me know and I'll work with you to get a copy of that clone to test the tools against it.
> 
> 
> Alright.
>