John,
John Peacock <jpeacock@rowman.com> wrote on 04.03.2005 18:49:50:
> That's a carbon-based error; just because you /can/ remove a tag doesn't
> mean you /should/. CVS doesn't prevent you from being stupid (to a
> large extent, neither does Subversion, but see below). You have to have
> a policy to deal with how you handle exactly this kind of procedure.
Yeah, but from a reproducibility POV, policy at time 'x' is not enough.
Suppose you update the whole structure of your repository, you change from
project/trunk to /trunk/project or vice versa. If I fix a revision by its
number, I can always consider such a structural update. Without the
revision number, I get stuck.
> Unlike some large commercial CM systems, you are allowed to set your own
> procedure, rather than having to do things the way "they" decided was
> correct. I view this as a benefit.
So do I. Not having to write a policy on this issue is an even greater
benefit IMO.
> > In Subversion, the precise location of a file is constructed of two
> > things: its location (path) in the repository and its revision number.
> > Tagging just changes the path but cannot guarantee that the contents
will
> > always be the same and can be referred to in this way unambiguously.
This
> > only holds if you additionally count for the revision number.
> No, a Subversion "tag" is a point in time copy of a portion of the
> repository. In fact, a Subversion copy is a pointer to the exact node
> that was the source at the point of the copy, and hence will never
> change, no matter what happens to the source file over time.
Of course. "Tagging just changes the path" was too loosely describing the
copy process. I wanted to make my point clear.
> If you
> treat your tag folder as write once (see below), you are guaranteed that
> each tag will point to the exact set of files that it always did.
Well, then you need a policy that forbids creating tags with names
reserved for future use. What would you do if someone accidentially
creates a tag named "release-2.5.1" if should've been "release-2.4.1"?
Then you have a useless nightmare of deactivating the hook script,
changing the tag (renaming the directory) and re-activating the hook
script.
Without this write-once policy I don't care about mistakes at tagging
(besides reverting the mistake).
If someone wants to refer to a version of a tag (and IMHO he always has
to), he just mentions the revision. So do the Subversion developers when
they refer to specific versions of files on the SVN-head (trunk). And it's
clear that creating separate tags for each commit to push the revision
number as a reference to the background, is useless.
>
> > "The issue is solved in rev. 105 of
> > http://server/repos/tags/project-x-release5/"
>
> Just be thankful that you can do it that way, too.
I am, that's why I'm _using_ Subversion and that's why I'm considering new
features :-)
> In CVS, the only way
> to refer to a set of files is by date or by tag (since the revision
> numbers are file specific). In order to completely define a set of
> files in CVS, you'd have to list each file and that file's revision.
That's what you have to do if you don't trust tagging operations. We don't
have to discuss CVS here, it was just an example. In CVS you can easily
remove, rename or copy repository,v-files or directories (assuming file
access to the repos) and break your complete history.
Even in Subversion, if you have to prove consistency (for example, if you
make a document or build a binary), you have to show that you
* checked out the correct revision (not tag!), check "svn info" for top
directory
* did not perform any modification to the files (not even updates to newer
versions), check "svn status -v"
* and check that all versions of "svn status -v" have the same number as
mentioned in "svn info" for the top directory.
... and a lot more. Consider certified products for automotive and
airospace applications. If a plane gets down you don't want to be the one
explaining why someone could change the tag you relied on to be static.
> Now, for the good news, although Subversion doesn't impose any specific
> meaning to the tags/ folder for your project, that doesn't mean _you_
> can't.
well, another issue for me (no specific meaning of tags and branches),
more on this next week ...
> Through the use of the pre-commit hook, you can make the /tags
> directory for a project be write-once (you can create a new tag, but you
> cannot rename a tag, nor change any files within that tag).
> I'm actually suprised that there isn't an example to do something this
> included with the source. I'm sure someone else has written something,
> but if no one speaks up, I'll do it myself, and it'll be in Perl, just
> to annoy the Python zealots... ;-)
Well, I am surprised to see so much information describing the behavior of
a database is stored in unversioned, text-based files (hook-scripts,
config files, access control). I think this topic requires a rewrite some
day anyway ...
- Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 4 19:26:29 2005