Section ID renaming (Re: [svnbook commit] r2657 - trunk/src/en/book)
maxb1 at ukf.net
Sun Mar 18 11:06:25 CDT 2007
>>>> * src/en/book/ch-advanced-topics.xml
>>>> (Network Model): Rework to be ... Pilatoan, and revert the changes
>>>> to the section IDs made when moving this section from the Server
>>>> Configuration chapter. (It was rather the point of using such IDs
>>>> to allow us to move sections around without breaking URLs in our
>>>> HTML forms of the book.)
>>> So uh, yeah, we *could* move sections around without breaking
>>> things... which is nice. But if it's trivial to rename them, why not
>>> do so? I only had to tweak 3 references. Isn't that better? Does it
>>> really make sense to have a bunch of sections named "svn.serverconfig"
>>> in a chapter full of "svn.advanced" sections?
>>> I have no sympathy for people making permalinks to a moving-target
>>> nightly build of the book's trunk. Ayita can eat my shorts.
>> But. But. But. But it was *the very reason* we did that whole ID renaming
>> thing, I thought!
> Hm? I thought the reason was much more mundane... that we got rid of
> numbers in our section id's so that we could rearrange sections
> without having to renumber all other existing sections.
> Maybe maxb can comment on this. :-)
Being able to insert, delete, and re-order sections without producing
insanity was definitely one of the reasons.
Another was being able remember ids so that when you're editing XML, you
don't *always* to have to go look up an id to write a link.
A particularly important reason, IMO, is to avoid ids ever getting
re-used for an unrelated topic - with the numerical scheme, this was
easily possible. With the symbolic scheme, you now only get links with
either work, or are broken - never a link which points to a valid
section, but which contains a totally different topic than it did in the
Complete URL stability is not possible, at least for the chunked
version, since any topic that is moved into a different <sect1> will end
up in a different chunked file, anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: OpenPGP digital signature
Url : http://www.red-bean.com/pipermail/svnbook-dev/attachments/20070318/65803592/attachment-0001.pgp
More information about the svnbook-dev