Subversion has been billed as the ³successor² to CVS. Granted, there are
many things such as tags that work in a different way. However, why is it
that some people take the attitude that the way subversion implements tags
actually covers the valid use-cases people had under CVS. Tags generally
are used for two types of things 1) a coherent release of a group of things.
2) An attribute or indication of quality on individual files which may or
may not be coherent as a group.
Please at least admit the fact that Subversion tags do not really implement
the use-case of identifying the ³status² of a set of files. You can use
Subversion tags for this, but it¹s really just an approximation. For
instance, I would really like subversion to support this use-case:
* In working on several files at the head of tree, I run through a series of
quality checks. Upon meeting quality criteria of a given type, I apply a
status tag to this file.
* Later, I gather all of the files with a particular status or tag to create
a release branch or more conventional tag.
While I understand your point, you wrongly assume that the subversion way is
appropriate for all cases. Subversion only deals with the second of these
two cases and ignores the first. Why is it wrong to support this use-case?
There are many other reasons to switch to subversion aside from tagging.
Versioning of the directory tree is critical. What a major PIA to do this
in CVS.
Why can't we have the current subversion-style tags for some instances while
supporting the "status" type tag use-case? Call it something different if
you like. In reality, subversion tags are really just branches, and
"status" is what in CVS was called a moveable tag.
-Steve
On 1/22/07 11:42 AM, "Kenneth Wood" <kenneth.wood@e2open.com> wrote:
> I guess I just can't believe it. Do people switch software tools with NO idea
> of how the tool works?
>
> This is like having a motorcycle that gets 60 MPG and then switching to a race
> car... then
> complaining that the race car only gets 2 MPG. If mileage was important, why
> did you switch?
> If CVS style tags are important, why did you switch to Subversion?
>
> The way subversion does "tagging" is, by design, NOT the same as CVS. I happen
> to
> favor the way Subversion does it, and look forward to using Subversion. I'm
> re-designing
> our current Version Control System to take advantage of how Subversion works,
> rather than
> worrying about the lack of CVS style tags...
>>
>>
>> -----Original Message-----
>> From: Leon Oosterwijk [mailto:leono@daveramsey.com]
>> Sent: Monday, January 22, 2007 10:34 AM
>> To: users@subversion.tigris.org
>> Subject: RE: Subversion tagging
>>
>>
>>
>> Hear Hear.
>>
>>
>>
>> After watching posts like this fly by over and over on the mailing lists I
>> thought I'd add my vote for such a feature as well.
>>
>>
>>
>> We switched from CVS to Subversion several months ago and this has indeed
>> been the single most confusing thing to my developers. We are a web
>> development shop and it is not uncommon for three or four separate releases
>> to our production site per day. Creating new branches for all of these is
>> not feasible, especially not for the graphics designers submitting images. I
>> set up a series of scripts to allow automatic merging of revisions using the
>> svnmerge scripts, but this has proven to be brittle and breaks easily on
>> conflicts.
>>
>>
>>
>> Very often my developers say 'I just want revision x to go to release'
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Leon
>
>
>>
>>
>>
>> From: Martins Kemme [mailto:mkemme@ml.lv]
>> Sent: Saturday, January 20, 2007 2:25 PM
>> To: users@subversion.tigris.org
>> Subject: Subversion tagging
>>
>>
>>
>> Hi!
>>
>>
>>
>> One of configuration management basic principles is keeping track of
>> configuration item status. This answers questions - which revision is
>> approved? which revision is deployed to production? etc. To provide this, it
>> is very common to apply tags to various file revisions. In SVN it is done
>> usually by copying files from trunk/ to the respective branch/* directory.
>> Unfortunately this operation is not straightforward from logical point of
>> view, because we create new file revision rather than apply a mark/tag (i.e.
>> "Approved", "Released") for a particular file revision. It is inconvenient
>> from practical aspect as well if every file version copy has a different
>> revision number. As a workaround for this technical issue we could create
>> "Approved" or "Released" branches in our repository, but this approach has
>> some drawbacks.
>>
>>
>>
>> Let's examine the following example - we need to track when a file revision
>> is deployed in production environment. In case we want to deploy all files
>> in particular revision, then we could create a copy whole trunk/ revision to
>> a new tag directory. Therefore we would create a set of tags (say
>> "in-production_on_Jan10", "in-production_on_Feb10") every time we deploy to
>> production. But what if we want to deploy a mixed revision file set to
>> production? We can't use svn copy functionality because then we would need
>> to pick by hand particular revisions of thousands of files (trunk is big!).
>> To workaround this we should create "branches/in-production" directory and
>> merge in there all mixed revisions of files that are promoted to production.
>> That would be an acceptable solution, if only ... this would not create new
>> revisions for all merged files. And here is the problem.
>>
>>
>>
>> If we are depicting revision number in file contents as well (using keyword
>> Revision), then after marking that this file is released, the in-production
>> version of a file contains different revision number than in trunk
>> (development). And if we would like to compare production revisions with
>> these in development trunk/ it comes down to comparing file contents again
>> as we can't rely on embedded revision numbers.
>>
>>
>>
>> So the question is - are there any plans to implement improvements in
>> tagging concept? More flexible solution would be an option to attach
>> tag/property to a particular file revision.
>>
>> Or, in case someone has good experience on how to track logical status of
>> all changes, please share your experience.
>>
>>
>>
>> Martins
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 22 18:09:36 2007