Hi,
Curious - how many reversion control systems have you used?
The only reason why tags are really necessary in CVS is because there is no
atomic changesets. In CVS its impossible to check out your files to a
consistent set unless you tag them.
In SVN that is not necessary since any given change number should
technically compile fine (if people donšt check in broken build). Project
management can map releases versions to releases to customer.
Another option is using the cheap branch faculity of SVN... Every time you
have an external release you create a new branch in /tags (or whereever...)
with a name like "v16may2003_draft_to_customer". You then have the
advantage of having a real branch. So you can patch and customize for the
customer on their release branch, and integrate it back to your mainline if
necessary.
Hope this helps.
Regards,
-ryan
On 5/17/03 9:25 AM, "Tom Browder" <TBrowder@cox.net> wrote:
> At the risk of getting shot, I would like to put in a plug for tags as in
> CVS. I have read the subversion book fairly closely and don't understand the
> rationale for treating a tag like a branch. As a lightweight CVS user, I
> appreciate being able to:
>
> 1. Use the rtag command to label snapshots in the development cycle with
> long tags that tell what the snapshot means, e.g.,
> "v16may2003_draft_to_customer."
>
> 2. Use the history command like so:
>
> cvs history -T | fgrep <module name>
>
> to see tags in date order.
>
> I also like the use of the environment variable CVSROOT to let cvs know the
> location of the repository. I think that would be very useful for
> subversion so one wouldn't have to enter the repository name, just the
> subdirectory of interest (whether remote or local).
>
> I'm ready to start trying subversion now that someone found the Berkeley DB
> problem with Rh 9. I look forward to what I see as the most valuable
> capabilities of subversion for my typical use:
>
> + ability to version binary files without completely duplicating the whole
> file with each change
>
> + ability to truly version the module tree structure
>
> + local change history (and revert capability) to aid development while on
> the road
>
> + ability to convert the working directory (or specific files) in place to
> a previous revision
>
> Thanks to all the subversion developers--this project has been sorely
> needed!
>
> Tom Browder
> SRS Technologies, Inc.
> Fort Walton Beach, Florida
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 17 18:55:20 2003