[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Moving tags on individual files (copy over/into exsting tag directory)

From: peter <subversion_at_cooltoad.com>
Date: 2006-01-07 22:46:38 CET

> I would like to know how I can move a tag from one revision of a file (or
> set of files) to another. Esentially I am looking for something that has
> the ease of use that CVS tags do.
>
> When I tried to copy a set of files into an exisitg tag directory I got an
> error message saying the tag already existed. As the --force switch does
> not seem to work with the copy command I don't see how there is way to do
> this.
>
> Am I missing something? Is there another way?
>

You are not the first one to be puzzeled by this question.
First you are right if a File exist there is no way to copy-overwrite
it. You have to remove it first. So somebody asked if it would be possible
to make this a bit easier by having a command which handels this.
But looking closely into the Problem you will find out that tagging
in subversion comes close to tagging like it was in cvs but is lacking 1
feature. You can't tag random files out of the middle of a large filetree
because the directory sructure doesnt exist.

Lets make this a bit clearer if you have a Projekt in trunk with lots of
files and you want to tag a single file which is all the way at the bottom
of a long filepath you cant't do that and preserve the original filepath.

I would be happy if somebody could proof me wrong an this.

So what can you do? Some people have pointed out that you could use
properties instead of tags.

Here is my original analysis of the tagging problem:

Some days ago ther was a discussion about tagging on this mailinglist.
Somebody wished for a simpler way to tag files. He wanted
to tag a file located at workingcopypath from taguri to trunkuri with a
command like

svntag -r rev workingcopypath tagname

There seemed to be some consens about this being fairly easy to implement.
In my oppinion this is not easy to do at all.
If you do it by hand on the command line you have to:

1. use svn info to get the trunkuri

2. if you don't want to tag the HEAD revision but an older revision you have to
check the log to find the path at that revision time.

3. remove taguri if it exists

4. create the taguri path if it doesn't exist

5. copy trunkuri to taguri

Explanations:
-------------

1. This is Easy just do a svn info workingcopypath

2. This happens for example when you have to change a file in the tag back to
an old version. Between the Head revision and your intended revision the path
of the
file might have changed. So you have to find the old path to use it at step 5.

3. if the file already exists in the tag you have to remove it first. The copy
in step 5
will not overwrite it.

4. This is a tough one and I think it is not possible to do it. For example if
you have
a file at svn://demo/trunk/src/java/gui/Frame.java and you want to tag(copy)
it to
svn://demo/tags/version3/src/java/gui/Frame.java the path
svn://demo/tags/version3/src/java/gui must exist. You could argue why don't
you just copy
the top folder like svn cp svn://demo/trunk/ svn://demo/tags/version3 but in
this case
you copy all the files I just want to copy a single file. Another idea would
be to
copy it into the tag folder like
svn cp svn://demo/trunk/src/java/gui/Frame.java svn://demo/tags/version3
but in this case you change the folder structure and it is hard to copy it
again from
the tag to someplace else.

5. This is the copy operation and no problem at all.

So am I overlooking somethig or is it really this hard to do? Especially step
4 was
really easy to do in CVS.

regards
Peter
  

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jan 7 22:50:51 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.