On Oct 9, 2006, at 05:40, Tanoor Dieng wrote:
> When we have decided that a file is stable we tag it like that:
> cvs tag -F STABLE myfile.
> When we want to publish a new version, a script will get a working
> copy composed by files with 'STABLE' tag.
> In this way, we can continue to work on our files while we are
> sure that only files with STABLE tag are put in production.
> I want to reproduce the same behaviour with subversion. But in
> subversion it seems that I have to create a directory in the
> directory named 'tag'. When I'm trying to create it from the
> repository or from a working copy, things work fine. But when I
> want to create a tag with mixed revisions, i just don't know how to
> do it.
> Does any one have more information?
You will need to rethink this for Subversion because tags and
branches are different in Subversion than they were in CVS.
First of all, you don't *have* to do anything with a directory called
"tag". Subversion is nothing more than a versioned file system. You
can call the directories anything you want. If you assign any meaning
to any directory then that's fine but it's only in your head, not
programmed into Subversion.
That said, the recommended conventions are good ones. Have a
directory "tags" where you copy snapshots of your code that never
change. Since your "STABLE" "tag" is something that will change, in
Subversion parlance that would be a branch, not a tag. Copy your
currently-stable code to branches/stable, then continue developing on
trunk, and when you next have stable items, merge them to the stable
branch. Merging is a big topic and is described in the book at
svnbook.org which you should read, if you haven't already. There's
even a section for people coming to Subversion from CVS.
Note also that in Subversion we don't usually talk about *files* but
about *revisions*. Just because this one change you made down here in
the file is ready to go to production doesn't mean this other change
someone else made up here in the same file is ready. So you would
merge the revision in which you made your change, but not the
revision in which that other person made their change.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Oct 9 20:22:32 2006