CODEWITHSUNDEEP
svntagsdocuments
CMKRIS
CMKRIS

Reputation: 21

How to handle changes to tagged documents in SVN

I have got few documents on trunk, they are updated for specific release and tagged with release number (documents on trunk will move on) and published across the company on release email. Problem – we are identifying changes required for the tagged documents (for example – typo somewhere or revision number mentioned for a module is wrong in RN). You might say update the document on trunk and create a new tag, in that case

  1. It will invalidate the original email.
  2. Base rule is no updates or deletion to tags once published across the company.
  3. To make it more complex documents tagged are referring each other with tag links. So a document update will trigger other documents to be updated.

I am wondering how could this be handled without resending release email with links still working and not encouraging deleting and recreating tag again(this will create bad practices down the road)?

please do forgive me if something is not clear and i will be more than happy to elaborate.

Upvotes: 2

Views: 76

Answers (3)

thekbb
thekbb

Reputation: 7924

Don't move a tag. Ever. The real value of a tag is a unique identifier - if you move it which version 5.1.9 are you referring too?

Upvotes: 1

leo
leo

Reputation: 81

This sounds, quite frankly, like you have to create a new release;

If not in place already, I'd suggest automating the creation of releases - you'll have to struggle much less if it only takes e.g. 30 minutes to make a release (compiling, testing, tagging, updating release log, circulating mail).

On top of that I'd raise the awareness in your company that you would need branches.

Possible short-term solution

I hope and fear at the same time that I got you correctly - please correct me if I'm wrong.

For "fixing" old versions when you are only allowed to work on trunk, the only solution that comes to my mind is to abuse trunk as a branch: Let's assume you found an error inside mydoc.txt at revision 56. In the meantime, people were working on it happily and repeatedly. After numerous changes, the last commit resulted in revision 89;

  1. "Update" the working copy of mydoc.txt to r56
  2. Perform the necessary changes
  3. Commit the change
  4. Update mydoc.txt to r89, again.
  5. Commit mydoc.txt, r89 into a new revision.

What happened here is that from 1-3, you actually worked on a branch. 4 and 5 are needed to repair this cruelty, again.

SVN will give you some thinking with performing 1-5, IMHO for good reason: this operation should be done on a separate branch. I'd go for proper branches at least for these kind of situations, not to speak of customers ordering changes on old versions.

Upvotes: 1

Attila
Attila

Reputation: 28762

I suggest you go the long path: leave the tagged version as-is, fix the errors in trunk (or maybe create a new branch just for these fixes), then create a new tag, send out updated email.

It is more painful, but creates less problems in the long run. The document references should be calculated automatically, so propagating all changes is less manual work and less error-prone.

If sending a new update email is an issue, make sure you double (and triple) check what you are releasing before release, but know that bugs have a tendency to be undetected until after release.

Another option is to have the above mentioned branch published to your beta-testers and create the tag only after you are fairly certain that there are minimal errors left.

Upvotes: 1

Related Questions