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

Re: early reflections on subversion methodology

From: Fabian Cenedese <Cenedese_at_indel.ch>
Date: 2005-08-12 11:29:20 CEST

>>If you have a look at some of the other (better) systems, you can see that banching and tagging are almost always built-in, not just implemented in the file system.
>
>Aargh. "built in" vs. "implemented in the filesystem"? Same difference. It is simply a question of how your UI represents branches and tags.
>
>BTW, because it lets you define branch and tag namespaces in any way you want, Subversion's way is _more_ flexible than most other VC systems I've seen. I think people are just irrationally afraid of this genericity and flexibility.
>
>Would you feel better if we had a "svn branch" and "svn tag" command?

I don't necessarily need these commands but maybe a better understanding
of the existing mechanism. In cvs it's possible to move a tag. How should
I do this in svn? Can I just copy the newer files over the old ones in the tag?
Or do I need to remove the tag first and then create a new one? What
about added/deleted files? I had a case where a "moved" tag (by removing
old stuff, copying new stuff) behaved slightly different (or maybe the client).
A wc of the old tag would get newer versions of existing files after the tag
was moved. But newly added files in the tag wouldn't get updated in the
wc, no matter how I'd update. One proposal was to use "svn switch" to
the new tag. I didn't try this yet but is this the regular way or just a
work-around? Shouldn't "svn update" always get the state of the tag, no
matter how this was created/moved/copied etc?

Thanks

bye Fabi

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 12 11:31:56 2005

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.