SVN Repository Status: Tags Created and Next Steps

[Eliot Kimber <ekimber@contrext.com>]

I have successfully created two tags in the SVN repo for the 1.2 and 1.3
releases.

My memory of SVN was faulty--I said on the call that tagging was just an
alias for a release number but that's wrong (that's how git works, but not
SVN).

In SVN a tag is just a directory within a directory named "tags" by
convention. 

I set this up so now in the repo there are the normal three top-level
directories "trunk", "branches", and "tags". The trunk and branches
directories are currently empty.

If you do an SVN update now you'll get both tag directories.

However, the organization of the repository is not optimal and does not
currently follow normal SVN practice.

Normal SVN practice is to have three top-level directories and only three:
trunk, branches, and tags. Within the trunk/ directory is then the files
being actively worked on.

What I would like to do is move all the files currently at the top level
into the trunk/ directory. This move can be done without losing any
revision history but it does require action by users with working copies
to react to the change.

Following this change, there would be two ways to react

1. Check out a new working copy, selecting the trunk/ directory as the
directory you're checking out. This would give you a clean starting point
reflecting the current files (once I've done the move) and you wouldn't
have the clutter of the tags/ directories in your working copy.

2. Use the svn "switch" command to switch your working copy to a new
directory. This updates your working copy in place:

svn switch --ignore-ancestry
https://tools.oasis-open.org/version-control/svn/dita/trunk

This command does not affect any local files not in the repo but you
should not have any uncommitted changes to files that are in the repo.

(You can try this command now--you'll switch to the currently-empty trunk/
directory.)


I would like to make this change now--we can broadcast the directory
restructuring to the DITA community and inform those people we know are
tracking the SVN repo actively (e.g., the OT team, Radu Coravu, etc.).

After this change, if somebody just did an update they would see the
movement of the files--it wouldn't be a destructive change, just an
annoying one.

If we make this change then, going forward, we can also then create a
branch from the 1.3 release to produce a 1.3 errata that is managed
separately from any new-release work done on the spec or we could create a
branch for new-release work and leave trunk/ as the 1.3 working set,
whichever seems more appropriate.

If we don't make this change then there is no easy way to get the working
versions of the files without also getting the tag directories.

Cheers,

E.

----
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com