Hi Simon,
thanks for the great introduction. This not only helped me to solve my
problem, but provided deeper insight!
Oliver
On Thu, 03 Feb 2005 15:06:23 +1300, Simon Kitching <[EMAIL PROTECTED]> wrote:
> Hi Oliver,
>
> I don't quite understand what you are trying to do. I hope the following
> helps (though I'm not an SVN guru, so others might correct this).
>
> Normally CVS "tags" are simply used to mark a set of files so that you
> can retrieve that same set later. In this case, the equivalent in
> subversion is just to use
> svn cp {from} {to}
> eg
> svn cp https://..../trunk https://.../tags/beta1
> to save the current state of the trunk as a directory "beta1". The copy
> command makes a "light-weight copy", essentially a sort of hard link
> with copy-on-write so updates don't affect the original source.
>
> If the trunk versions move on, and you later want beta1 to include one
> of the updated files, then update what "beta1" refers to by relinking
> from the beta1 directory to the version you really want:
> * removing the file (link) you no longer need from the "tag" dir
> eg svn rm https://....../tags/..../foo.txt [1]
> * copying back in (ie link to) the version you want
> eg svn cp
> -r 100 https://..../trunk/.../foo.txt [2]
> https://..../tags/.../foo.txt [3]
>
> [1] or if you have a working copy of the tag dir, you can
> do svn rm and svn commit
> [2] if you want the latest version, just omit the -r 100.
> [3] or if you have a working copy of the tag, copy to your working
> copy then svn commit it.
>
> Performing the copy again (ie linking to the *updated* file [together
> with its history] from the tag) is what Brett means by "copy with
> history again". Using "svn merge" doesn't do the same thing, because it
> is effectively generating a patch file then applying it to your version;
> the differences get merged in, but not the history.
>
> Alternatively, if the "updated" tag is meant to look mostly or
> completely like the new trunk, then just use "svn update" to ensure your
> trunk working copy looks like the stuff you want to tag, then delete the
> old "beta1" directory, and recreate it. Copies are cheap!
>
> There isn't any difference between a directory created with the intent
> of just using it as a "tag" and a directory created with the intent of
> using it as a branch. The convention of putting the scn copy into
> subdirs "{project}/branches" and "{project}/tags" are traditionally used
> to *indicate the intent* of the copy, but they are functionally
> identical.
>
> For some other traditional uses of CVS tags, it might be better to use
> subversion "properties" (see svn set-prop).
>
> I suggest you read the subversion manual, particularly the section on
> branches. It is very well written..
> http://svnbook.red-bean.com/
>
> Regards
>
> Simon
>
> PS: Bottom-posting would have made this thread much more readable!
>
> On Thu, 2005-02-03 at 01:44 +0100, Oliver Zeigermann wrote:
> > Yes, that's what I was trying. However, merging the new stuff in
> > generated a new trunk inside the tag (which seems to be just like a
> > branch). Isn't there anything similiar to CVS moving a tag?
> >
> > Thanks anyway :)
> >
> > Oliver
> >
> >
> > On Thu, 03 Feb 2005 06:32:26 +1100, Brett Porter <[EMAIL PROTECTED]> wrote:
> > > You mean retag a file that has already been tagged?
> > >
> > > You can probably copy with history again. If that doesn't work, it's
> > > probably a matter of essentially merging the changes since the file was
> > > "tagged".
> > >
> > > Remember, svn doesn't really tag anything and there is nothing magic
> > > about the trunk, branches and tags directory. They are all just copies
> > > (with history).
> > >
> > > - Brett
> > >
> > > Oliver Zeigermann wrote:
> > >
> > > >Folks,
> > > >
> > > >sorry, this is a bit OT, but I am struggeling how to move a tag in SVN.
> > > >
> > > >Any hints?
> > > >
> > > >Thanks in advance,
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
