On Fri, Dec 01, 2006 at 02:23:52PM -0600, Bob Hiestand wrote:
> On 12/1/06, Chris.Fouts@qimonda.com <Chris.Fouts@qimonda.com> wrote:
> >>Since you know how to reuse tags, please describe how the
> >>different implementation in SVN doesn't fit your requirements?
> >> For me, the functionality is the same.
> >
> >You got me here, sorry for leaving the relevant context.
>
> I'm not trying to get you, I'm trying to understand how tags in SVN
> don't do at least as much as tags in CVS. The only issue that I've
> personally encountered with respect to the branch model is that it's
> easier (faster?) to trace changes made in other branches. This is
> something that doesn't come up very often
Actually it came up just today. We couldn't figure out why a
particular line was in the config file. So we did an svn blame, read
the log message and got a bit of a clue. Then checked the ticket
associated with the change (encoded in the log message yech) and found
out why the more efficient change we were going to do wouldn't work.
The problem with using an svn branch as a label is that it doesn't
relate to the original tree at all. The search I did above had dozens
of changes that (should) never have made it into production, but I had
to wade through them anyway.
What I am currently working through is to have a branch called
production. When I need to copy files from testing -> production I
need to:
svn rm the file in the production branch
svn cp the file from test to production
(why doesn't copy just copy over the existing production file and
create a new version. Anyway...)
Repeat for each file that needs copying (leaving the production tree
in an inconsistant state while the copies are going on). Now in
production if I want to use 'svn annotate' I really can't since the
removal of the file clobbers the history for the file. I can get to
the older version by somehow divining the peg revision (which isn't
trivial) and I (assume) I can diff them using 'svn diff
production/path production/path@PEG'. However 'svn log' stops at the
copy (well goes down the trunk) not down the branch history.
Also if I want to figure out which revisions of which files in my
testing tree made it into production I can do a linear search down the
production tree and look at every single copy for every single file at
each revision. Takes a while, but that is required for some audit
senarios.
> (only when a merge has
> issues), and is partly a consequence of the fact that I don't use any
> tool other than the command line.
Or when you are trying to discover why something was done the way it
was.
> As far as I can tell, the requirements I and my organization have for
> tags are met by SVN quite well, and in fact better, than by CVS.
> That's why I'm trying to understand the tags use case that SVN doesn't
> address that CVS does.
>
> >>On the other hand, CVS doesn't inherently stop you from moving
> >>tags, thereby losing history of how they were placed, which
> >>SVN doesn't do.
This is true, but by policy you can choose to use both floating and
static tags.
> >It's changing the "concept" that I don't prefer (note I said
> >"prefer"). Historically, in other revision cotrol systems -
> >CVS, clearcase, Perforce(?) - tags/labels are NOT branches,
> >but in SVN, they essentially are. I'd rather separate the
> >two.
>
> Fair enough. I think it just may be part of the learning curve of SVN
> (repository revision vs file revision, and tags and branches as
> copies) that frustrates people. I think that both concepts have very
> positive results, however.
It is just that SVN doesn't implement the work model a number of us
are describing. Mainly mixed revision from the trunk being used
together.
We need to be able to track which trunk revisions of individual files
were used in creating a branch, and we need to be able to update the
branch maintaining the trunk->branch history as well as the branch
history (to see which versions of the trunk files have been placed in
production).
CVS tags do that very well as they:
exist on the time axis of the trunk (not in some
unconnected spacial component)
can be moved to capture the current "head" revision of the branch
(and can be permanetly marked to allow rollback fo a head of a
branch)
can NOT tag items that are not checked into the trunk.
enforce tag renames via taginfo (so you can change PRODUCTION
but not PROD_200612011622)
As a result I can:
use annotate on the trunk to find the original point where a line
was entered
use log to discover what tags/labels are associated with the file
revision
using log to determine if the revision ever made it into production
(possibly triggering a massive security sweep if it did.)
automatedly update files from a known static location.
Does this make my use case a little clearer?
--
-- rouilj
John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 1 22:13:44 2006