On 27/06/06, John Rouillard <rouilj@renesys.com> wrote:
>
> This leaves each file in the production tree at a different merge
>
revision making merge tracking difficult at best.
>
> I would be interested in your mechanisms for tracking this sort of
> thing.
Well we don't merge very often - if a developer wants to put a revision into
production he has to put all files for that revision into production. If
there is a "blocking" revision then he either has to take that revision as
well, or do a merge, and he usually opts for taking the blocking version.
So if I have a directory at rev. 10 and a developer commits rev. 20 where he
touches files A & B then he updates files A and B to version 20. This works
fine, as long as there are no other changes between rev. 10 and rev. 20.
If, for example, rev 15 involves files B and C then he has to explicitly
take version 15 as well (and check that file C isn't touched between rev 10
and rev 15). That means that svn info is usually enough to tell what
version of file we're looking at.
What I ended up doing was writing a small program that scans the working
copy for files later than a certain version (that version having been
certified by QC) and remembers them. Then I do a global svn up -r whatever,
followed by updates of the individual files that had later revisions.
I'm not sure if this corresponds to your scenario, doesn't really sound like
it ...
Thanks for your input,
R
PS It seems that the performance hit for tag creation comes when you have
lots of mismatches between a parent directory and its children, if anybody's
interested
Received on Wed Jul 5 15:52:22 2006