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

RE: Is this a bug or a feature?

From: Will Gant <WGant_at_brookdaleliving.com>
Date: Mon, 13 Jul 2009 11:10:52 -0500

I guess I'm still a bit lost. I'm puzzled as to why subversion copies
the new data into a child directory of the target rather than throwing
an error out or overwriting. I'm not sure what the purpose of that
feature would be.

 

William Gant

Programmer Analyst I

Brookdale Senior Living

111 Westwood Place Suite 200

Brentwood, TN 37027

(615) 564-8138 P

(615) 234-7309 F

wgant_at_brookdaleliving.com

 

________________________________

From: David Weintraub [mailto:qazwart_at_gmail.com]
Sent: Monday, July 13, 2009 11:04
To: Will Gant
Subject: Re: Is this a bug or a feature?

 

When you create a tag in Subversion, Subversion doesn't understand it is
a "tag". To Subversion both tags and branches are simply directories
that you just happen to treat as special.

This causes quite a few problems, especially with tags: There is no way
to lock a tag. As you found out, you can "create" a second tag over the
first. And, you can easily modify a tag, and you can do this quite
accidentally.

Fortunately, there is a way to prevent this. The standard Python
pre-commit hook permissions hook has the ability to create a "add-only"
permission that is very useful to tags. If a directory (such as the
"tags" directory) is marked "add-only", you can only add new directories
into that directory, and you are not allowed to modify or overwrite any
files inside that directory.

If you use this pre-commit hook, you can make it, so you can only create
new tags, and you will not be able to overwrite or modify a tag.

On Mon, Jul 13, 2009 at 11:35 AM, Will Gant <WGant_at_brookdaleliving.com>
wrote:

Greetings,

I'm working with subversion using the commandline client on Windows (I'm
trying to set up a build task that will create a tag when the project is
deployed to test). We are currently using Subversion 1.4 server, with a
1.6 client. I'm not sure if this is an actual bug or a misunderstanding
on my part, so I wanted to run it by the list to make sure I'm doing
anything dumb first.

 

Currently, I'm doing the following.

When a build finishes, I issue an "svn copy" from the current project
trunk to a folder that is supposedly a new tag. The tag name is
determined from the version number of the executable code. However,
there are cases where the version number of the executable might not be
changed (if there are changes in supporting files used by the app that
aren't packaged in the binary). So, it is possible to copy to an
existing tag. When I try to do that however, instead of getting an
error, subversion appears to dump the same set of files in a directory
underneath the target.

 

So, for instance, when I do the following:

svn copy "svn://TestServer/MyLameApp/Configs"
"svn://TestServer/MyLameApp/Tags/V1.11.1.1"

it moves the files under the configs folder into the V.1.11.1.1 folder.
However, if I call it again, it copies all the files under the configs
folder into V1.11.1.1/Configs.

 

I'm not sure if I'm doing this incorrectly or if it is a bug. Does
anyone have any suggestions?

 

Thanks,

 

William Gant

Programmer Analyst I

Brookdale Senior Living

111 Westwood Place Suite 200

Brentwood, TN 37027

(615) 564-8138 P

(615) 234-7309 F

wgant_at_brookdaleliving.com

 

 

----------------------------------------- This email may contain
confidential protected health information and/or attorney privileged
information. If received in error, see our Privacy Statement at
http://www.brookdaleliving.com/privacy-policy.aspx

-- 
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2370970
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-13 18:12:14 CEST

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.