2

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.

thekbb
  • 7,668
  • 1
  • 36
  • 61
CMKRIS
  • 21
  • 1

3 Answers3

1

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.

Attila
  • 28,265
  • 3
  • 46
  • 55
  • Hi Attila, Thanks for reply&appreciate ur time.I should have been more clear might be. there are two aspects here 1. Code 2. release documents both are at different locations and each have its own trunk and both are tagged at end of each sprint. 1. Code is worked on a branch and if any changes after tagged is considered as a different release 2.Problems to manage this as req corrections in release documents after the release email send out(like typos, incorrect links&revision ment for modules)which does not require any changes to code but documents need to be updated. hopefully this makesense? – CMKRIS Oct 25 '13 at 13:59
  • @user2919782 - What I wrote applies to both repositories. – Attila Oct 25 '13 at 14:00
1

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.

leo
  • 81
  • 4
  • Hi Leo, Thanks for reply&appreciate ur time.I should have been more clear might be. there are two aspects here 1. Code 2. release documents both are at different locations and each have its own trunk and both are tagged at end of each sprint. 1. Code is worked on a branch and if any changes after tagged is considered as a different release 2.Problems to manage this as req corrections in release documents after the release email send out(like typos, incorrect links&revision ment for modules)which does not require any changes to code but documents need to be updated. hopefully this makesense? – CMKRIS Oct 25 '13 at 14:11
  • I would even go further and consider the release documents to be part of the release: After all, they are strictly speaking just a human-readable representation of the code. If the code is correct, even better: You only have to make a new release for the same source code tag... – leo Oct 25 '13 at 14:33
1

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?

thekbb
  • 7,668
  • 1
  • 36
  • 61