#24976 closed task (blessed) (fixed)
Implement develop.svn.wordpress.org
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | 3.7 | Priority: | normal |
| Severity: | normal | Version: | 3.7 |
| Component: | General | Keywords: | |
| Focuses: | Cc: |
Description
As enumerated here: http://make.wordpress.org/core/2013/08/06/a-new-frontier-for-core-development/.
This ticket is for the initial implementation. Once fully committed, this ticket will be closed and any issues, suggestions, or improvements can come in new tickets.
Attachments (3)
Change History (34)
#2
@
11 years ago
[25001] switched from using YUICompressor (via bumpbot) to UglifyJS2 and clean-css, via Grunt. Hence, the sync commit to core.svn is modifying every minified file.
#4
follow-up:
↓ 6
@
11 years ago
[25002] added two externals: The pinned but still hefty wpcom-themes external, and the wordpress-importer external.
I am all for us testing the importer as if it were a part of core. But let's remove the wpcom-themes external. I was going to suggest we should rework those tests, but I think we should just ditch the Tests_Theme_ThemeDirLarge tests altogether. WP_Theme solved this problem once and for all in 3.4. And also, because it is a pretty lame test. :-)
#6
in reply to:
↑ 4
@
11 years ago
Replying to nacin:
I am all for us testing the importer as if it were a part of core. But let's remove the wpcom-themes external. I was going to suggest we should rework those tests, but I think we should just ditch the Tests_Theme_ThemeDirLarge tests altogether. WP_Theme solved this problem once and for all in 3.4. And also, because it is a pretty lame test. :-)
Agreed.
#7
follow-up:
↓ 9
@
11 years ago
Also, in regard to the importer, I think it would also be better if we eventually managed to pull those tests into the plugin itself, and run those tests separately like any other plugin would (also helping set the example for other plugins).
When the dust settles, maybe this is something Frederick might want to look at post GSoC?
#9
in reply to:
↑ 7
@
11 years ago
Replying to bpetty:
Also, in regard to the importer, I think it would also be better if we eventually managed to pull those tests into the plugin itself, and run those tests separately like any other plugin would (also helping set the example for other plugins).
That does make sense. I'd want to make sure any importer tests are not neglected, especially in terms of being broken by core changes. We'll probably just want to make sure we hook it up into Travis CI.
#12
follow-up:
↓ 26
@
11 years ago
I set up a redirect from http://develop.trac.wordpress.org/ to http://core.trac.wordpress.org/.
Additionally, if you go to a /browser/trunk/wp-* URL, with no query string (so no ?rev=12345), it'll redirect you to the proper URL with /src. This should prevent a lot of link rot from elsewhere on Trac, mailing lists, etc.
Example:
http://core.trac.wordpress.org/browser/trunk/wp-admin/ redirects to http://core.trac.wordpress.org/browser/trunk/src/wp-admin/
http://core.trac.wordpress.org/browser/trunk/wp-admin/?rev=25000 does not redirect.
This also works for /log/. And you'll note from the last example that r25000 has some nice practical implications, too — easy to remember.
#13
follow-up:
↓ 16
@
11 years ago
I notice a .gitignore was added along side svn:ignore, that in itself isn't an issue, but I noticed that the .gitignore ignores a lot more than than the SVN equivalent, is there any need for us to sync those a bit more?
#14
@
11 years ago
Seems something funny is going on in Trac
For example, on http://core.trac.wordpress.org/browser/trunk/src/wp-includes/admin-bar.php the Blame link lacks the src/ path, however the Previous Revision link works (and it links to the non-src/ url, as that's where the file was at the time).
But then take a file that's been modified since the move, such as http://core.trac.wordpress.org/browser/trunk/src/wp-includes/script-loader.php, and the Blame link is fine, but the Previous Revision link is missing.
#16
in reply to:
↑ 13
;
follow-up:
↓ 17
@
11 years ago
Replying to dd32:
I noticed that the
.gitignoreignores a lot more than the SVN equivalent, is there any need for us to sync those a bit more?
Think so, also perhaps ignore wp-tests-config.php and .htaccess.
#17
in reply to:
↑ 16
@
11 years ago
Replying to azaozz:
Think so, also perhaps ignore wp-tests-config.php and .htaccess.
I was about to add that, and phpunit.xml, but I'm still waiting on commit access to be transferred over.
#18
follow-up:
↓ 20
@
11 years ago
...and phpunit.xml
Right, with <phpunit colors="true"> PHPUnit is still not clever enough not to output console colors on windows making it look really broken :)
#22
@
11 years ago
The svn-ignore property is not recursive like .gitignore. It applies only to the current directory and doesn't accept sub-directory paths as values.
In Subversion 1.8 (came out about a month ago) there are two new properties: svn:global-ignores and svn:auto-props. Global-ignores is recursive and auto-props can be used to set things like svn:eol-style and svn:mime-type for new files.
#23
@
11 years ago
svn-ignore.patch adds "old style" svn:ignore to . including .htaccess and *.log, to ./tests and to ./src/wp-content for uploads and blogs.dir.
trunk-global-ignores.patch adds svn:ignore to . for .htaccess and *.log, and svn:global-ignores for wp-config.php, wp-tests-config.php, etc.
trunk-auto-props.patch adds some svn:auto-props for new files.
#26
in reply to:
↑ 12
@
11 years ago
Replying to nacin:
Additionally, if you go to a /browser/trunk/wp-* URL, with no query string (so no ?rev=12345), it'll redirect you to the proper URL with /src. This should prevent a lot of link rot from elsewhere on Trac, mailing lists, etc.
This has now broken for http://core.trac.wordpress.org/browser/trunk/wp-config-sample.php and wp-tests-config-sample.php after [25173]
In [25001]:
New develop.svn.wordpress.org repository based on the old core.svn repository.
props koop.
see #24976.
and see http://wp.me/p2AvED-1AI.