On 12/1/06, John Rouillard <rouilj@renesys.com> wrote:
> 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.
So in two operations (svn blame and then svn log) you found what you
were after? That seems reasonable to me. How can this be simpler?
> 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.
In CVS (which I invoke as it appears to be the point of comparison,
rather than the requested label design) you have to wade through
exactly the same information. It would be simpler only if the change
was merged through multiple branches, thus necessitating (in SVN)
running multiple instances of the search commands.
CVS functionality, on the other hand, fails entirely in this if you
ever want to trace a renamed file. Rather, it gives you the choice:
either be able to follow renamed files through their history, or be
able to reconstruct the state of the repository at a branch at any
time. You can't have both. The SVN method of versioning the file
system instead of individual files solves this issue.
> 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...)
I think this is the problem. Without specific knowledge of your
process, this is not a good fit for the tool and your expressed
requirements.
Instead of copying individual files, you should be recreating the tag
entirely. If you do that, the file history you believe is missing is
preserved transparently.
> 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.
All this goes away if you don't try to promote individual files. Is
there a reason you are doing it that way?
> 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.
Simply running svn info on the files will tell you the last-changed
revision, which for this purpose is the same as the CVS revision
number from cvs status.
> > >>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.
Right, a lot of work flow must stem from individual policies. The
point I was making above is that SVN allows you to retrieve the
previous state of a floating tag, which isn't possible in CVS.
> 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.
From your last message, I think SVN can implement your work model.
However, I haven't seen a great deal of detail about your specific
process.
> 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:
Actually, no they don't. You can't ask in CVS "which versions of this
file have ever been in production?". You can in SVN.
> exist on the time axis of the trunk (not in some
> unconnected spacial component)
While not connected as much as would be convenient, they are not unconnected.
> 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)
Supported by SVN. Even better, this is supported by an atomic change,
which CVS doesn't allow. Ever delete a file and re-tag your working
directory in CVS? You just created a problem, because the old version
of the file still has the tag.
> can NOT tag items that are not checked into the trunk.
You can of course tag items that have never been on the trunk in CVS.
Here I think you mean that you can't tag revisions that haven't been
checked in. I am not very experienced with SVN hooks, having only
implemented simple checks, but I believe you can probably prevent this
by allowing only copies in the /tags directory scheme, and not
changes.
> enforce tag renames via taginfo (so you can change PRODUCTION
> but not PROD_200612011622)
Supported also by SVN hooks.
> As a result I can:
>
> use annotate on the trunk to find the original point where a line
> was entered
Subject to the caveats of renames, as above. And, as above, this
takes the same amount of work in SVN unless you're following a change
that was merged from one branch to another several times.
> use log to discover what tags/labels are associated with the file
> revision
Yup, this isn't easy in SVN. It also doesn't seem to be a common
operation. Normally, I am asking the other question: What was in
this tag?
> using log to determine if the revision ever made it into production
> (possibly triggering a massive security sweep if it did.)
As mentioned above, this is absolutely not possible in CVS. You can
determine whether a revision is CURRENTLY in production, but not
historical information. Unless, of course, you mean by retaining the
type of PROD_timestamp tags you mentioned in passing, in which case
you are correct, as it is simply a restatement of the previous point.
> automatedly update files from a known static location.
I'm not sure exactly what you mean, but this sounds like basic source
control, which is supported by SVN (otherwise no one would use it :).
> Does this make my use case a little clearer?
Not yet. How do you use branches in your process? My vague
understanding is that your process is mostly single-branched.
Thank you,
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Dec 3 03:53:54 2006