On 27/06/06, John Rouillard <email@example.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
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
Thanks for your input,
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
Received on Wed Jul 5 15:52:22 2006