Section ID renaming (Re: [svnbook commit] r2657 - trunk/src/en/book)

[Max Bowsher]

cmpilato:
>>>> * 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.)

sussman:
>>> 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.

cmpilato:
>> But.  But.  But.  But it was *the very reason* we did that whole ID renaming
>>  thing, I thought!

sussman:
> 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
past.


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.

Max.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: OpenPGP digital signature
URL: <http://www.red-bean.com/pipermail/svnbook-dev/attachments/20070318/65803592/attachment.sig>