Danny van Heumen wrote:
> Branko Čibej wrote:
>
>> Danny van Heumen wrote:
>>
>>> Tag is:
>>> 1. An alias for a revision number.
>>> a) Single revision
>>>
>>> 2. An alias for multiple revision numbers.
>>> a) Multiple revisions.
>>>
>>> 3. An alias for a revision number for a specific location.
>>> a) Single revision
>>> b) Specific location
>>>
>>> 4. An alias for a collection of revisions for a specific location.
>>> a) Multiple revisions.
>>> b) Specific location.
>>>
>>> 5. An alias for a collection of revisions for a specific location with a
>>> possibility for adding non-versioned files (and folders etc.)
>>> a) Multiple revisions.
>>> b) Specific location.
>>> c) Versioned + non-versioned files.
>>>
>>> If I understand correctly Subversion currently supports the fifth
>>> concept, which is also the most extensive.
>>>
>>>
>> There is no such thing as a non-versioned file in Subversion, so they
>> can't be part of a tag.
>>
> Well, It's a scenario I found in the mailing list a while ago. Someone
> explained that he made tags, but he included files that weren't
> versioned earlier.
> The example he gave was: They build the binaries. They normally don't
> version them, but when they create a tag for a new release they do. So
> they create a tag with both the source files (for the new release
> version) that are already present in the repository and the newly
> generated binaries that aren't yet versioned.
> Of course when you commit all files are versioned.
>
Ah. Yes, it's certainly possible to do that.
> But... thinking about it... "adding the binaries to the tag" may be a
> separate action (done after creating the tag) and in that case '5' is
> not a valid concept. (Need some help here ;)
>
Heh, it's basically a question of how orthodox you want to be in your
definition of a tag. I know quite a few VC systems where tags are
anything but immutable, and when you change such a tag, all information
about its previous "value" is lost. In SVN, of course, such historic
information is never lost, so it would be more proper to talk about
"redefining" rather than "changing" a tag.
> Quote:
> "Tagging the working copy, e.g., after a successful build, involves
> copying a directory in the repository, *and* committing all the working
> copy modifications to the copy. In this type of tag, the copy contains
> some information found nowhere else in the repository, so it can't be
> represented by a URL and revision."
>
> Found here: http://svn.haxx.se/dev/archive-2006-03/0882.shtml
>
I'd say that's a valid definition; IMHO the tool should serve your
process, not the other way around.
FWIW, Subversion's release process calls for modifying tagged files --
or at least, it used to; I'm not on top of things these days.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 9 14:56:51 2006