On Monday 05 March 2007 10:17, Peter Kahn wrote:
> [for those unfamiliar with cvs, a tag can be viewed as a group
> of files each at a specific version]
>
> So, I'd like to have a flexible structure that allows me to group a
> variety of different versions of files together and call them a
> build. In CVS, I can use a tag (or a branch as well) for this. In
> SVN, I believe that my only option is to branch & merge (agreed,
> with the tags branches being read only after creation).
Peter,
It's possible that you are having a hard time leaving behind the
mind-boggling complexities of CVS. Subversion does same but simpler.
Maybe if you post an example as a sequence of one-liners (like I do
below) then one of us can help you work out the translation.
I perceive that you have trouble because you are keeping in your mind
the two different ways that cvs tracks tags and branches internally.
I can tell that deep down you know the two are much the same:
* A [tag] is a tree of files given a name, and selected from
certain revisions of certain files.
* A [branch] is a tree of files given a name, and selected from
certain revisions of certain files.
Then why does cvs track them two different ways? Why to make it more
complicated, of course ;-)
I hope you will allow yourself to just forget how cvs works--wipe your
memory and start from a clean slate, just long enough to see the
_same_ procedures but from a subversion point of view. I am amazed
how easy it is to do the same thing using only 'copy'. BTW the reason
cvs does not use 'copy' instead of 'tag' is because it would have to
duplicate the entire contents of actual files in the repository, and
we don't want that kind of mass redundancy. That's why subversion
uses "cheap copies", i.e. new path only references the original.
How I do same stuff with Subversion:
(Note1 the paths are relative because I am in the root of my working
copy which contains trunk, tags, and branches. It could be done many
different ways for different benefits, so RTM)
(Note2 It is important to realize that sometimes `svn ci` and/or `svn
update` is needed even though I left it out)
1. Say I use /trunk/pname for our "mainline" development of the
"pname" project.
2. Soon I have some releases which I have tagged:
`svn copy trunk/pname tags/build.1` :tag current dir as "build.1"
`svn copy trunk/pname tags/build.2` :tag current dir as "build.2"
3. I want to work off of build.1 now for small bugfix.
`svn copy tags/build.1 branches/build.1-fix1` :branch from "build.1"
[fix bug in branches/build.1-fix1]
4. I realize I need "sub" folder to be at build.2
`svn switch svn://localhost/r/tags/build.2/sub
branches/build.1-fix1/sub` :mixed revisions in this working copy
5. It builds and works, so I tag this as build.3
`svn cp branches/build.1-fix1 tags/build.3
I haven't tested these commands exactly, but I've used all of these
methods in the real world. Hope it helps clarify.
P.S. One difference from cvs to svn is which repository you commonly
use. Instead of setting env variable CVSROOT (because no equiv in
svn), I use this to shorten the commandline:
REP=svn://localhost/robo
cd branches/build.1-fix1/sub
svn switch $RROBO/tags/build.2/sub
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 8 17:37:35 2007