Closed Bug 504442 Opened 16 years ago Closed 16 years ago

Remove content/html/parser and land parser/html/javasrc/*.java

Categories

(Core :: DOM: HTML Parser, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: mozilla+ben, Assigned: mozilla+ben)

References

Details

Attachments

(1 file, 1 obsolete file)

Secifically, land those files that used to live in content/html/parser/javasrc/. The diff should reflect this correspondence by renaming rather than deleting/adding.
Attached patch relocation patch (obsolete) — Splinter Review
Small patch because we're just 'hg mv'-ing the .java files.
Depends on: 499141
Attachment #388814 - Flags: superreview+
Attachment #388814 - Flags: review+
Is htmlparser/ a copy of the htmlparser svn repo? If so, htmlparser/src/*.java doesn't look like the right location. Can we put the snapshot of the *.java files that were used for code generation outside the directory that the svn repo checks out to (e.g. to parser/html/javasrc/*.java)? The snapshot that is now at content/html/parser/javasrc/*.java is likely to be often out of sync with the svn repo when stuff has been checked into the svn repo but hasn't been reviewed for m-c yet.
(In reply to comment #2) > Is htmlparser/ a copy of the htmlparser svn repo? If so, htmlparser/src/*.java > doesn't look like the right location. parser/html/java/htmlparser/src is a working copy of http://svn.versiondude.net/whattf/htmlparser/trunk/src/nu/validator/htmlparser/impl > Can we put the snapshot of the *.java files that were used for code generation > outside the directory that the svn repo checks out to (e.g. to > parser/html/javasrc/*.java)? The snapshot that is now at > content/html/parser/javasrc/*.java is likely to be often out of sync with the > svn repo when stuff has been checked into the svn repo but hasn't been reviewed > for m-c yet. In short, yes, I think this is a good idea. I was thinking that a given hg revision of parser/html/javasrc/*.java (note that javasrc is a symlink to java/htmlparser/src) would simply correspond to the same revision of the generated files. Changes committed to the svn repo wouldn't be synced into the mozilla-central tree unless the translation was also updated. That's what I thought, at least. I'm not opposed to breaking the symlinkage and letting the translator copy the files from parser/html/java/htmlparser/src to parser/html/javasrc (that's what it does now, but the copy is a no-op since javasrc is a symlink to the same directory). Then parser/html/javasrc would be what gets committed, I presume. The symlink felt like a hack anyway.
Summary: Remove content/html/parser and land parser/html/java/htmlparser/src/*.java → Remove content/html/parser and land parser/html/javasrc/*.java
Depends on: 504646
Updated parser/html/javasrc/README.txt to explain the situation.
Attachment #388814 - Attachment is obsolete: true
Attachment #388985 - Flags: review?(hsivonen)
(In reply to comment #4) > Created an attachment (id=388985) [details] > Relocating to parser/html/javasrc instead of parser/html/java/htmlparser/src Pushed to mozilla-central: http://hg.mozilla.org/mozilla-central/rev/cda81bfef31e
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: