> <RS>>>>>Do not think of it as the version number (or more properly:
> revision number) *of a file* or *of a directory* but instead *of the
> repository*. Attach no further meaning to this number other than "the
> number of changes that have been made to the repository." That's all it
> Good evening, Ryan.
> Yes, I understand that. But, if the current revision of the SRS is 4.3 (as
> recorded in the change log on the back page of the document), and someone
> comes to me and tells me that he needs revision 4.1 and wants to know how
> he can check it out, what do I tell him if the whole repository is at
> revision 17?
As others have noted this is a perfect example of tags. Think of the
workflow as the following.
1. People work no documents on trunk. They makes changes, commit them
for sharing amongst the team. These are draft changes.
2. The team decide the documents are at a point for 'publication'.
Copy the trunk to a tag and name it with the 'publication version
3. goto 1 and work towards the next publication.
Individual draft changes are identifiable via 'svn log' which will
list the revision number, log message and user. Published revisions
are explicitly versioned and are found in the tags folder (or whatever
you want to call it).
If the files were able to be merged (non-binary) then you could
actually branch from trunk and finalise the publication through
peer-review before actually publishing to a tag. There are a lot of
options here - subversion is quite flexible in nearly all respects
except for providing individual revision numbers for files.
> This is aside from the issue about if he wants the SRS he'll have to check
> out everything else in that repository directory including stuff he doesn't
> care about.
Not being able to check out individual files is a little inconvenient.
But don't interprete this as the need to check out the whole
repository, you can absolutely check out a given folder in the
repository so you can still partition documentation by subject,
project or whatever suits. I'd recommend that this be planned out a
little though since if you utilise tagging you'll probably want a tags
folder per subject/project.
> (I suggested that the only real "fix", in that case, would be to put each
> file into its own repository and I thought I was going to be lynched...) :-(
Please don't do that. I can't see this as even remotely a rational
solution. If nothing else, managing backups and repository
verification for dozens and dozens of microscopic repositories is far
from using time productively.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Nov 7 20:44:25 2006