On 20.01.2007, at 21:25, Martins Kemme wrote:
> If we are depicting revision number in file contents as well (using
> keyword Revision), then after marking that this file is released,
> the in-production version of a file contains different revision
> number than in trunk (development). And if we would like to compare
> production revisions with these in development trunk/ it comes down
> to comparing file contents again as we can't rely on embedded
> revision numbers.
I think there are two solutions, if I got you right:
first is that you currently seem to be working on the "old" version
in terms of your tracking of "marking version as released"
you could put a file in there which you write the current revision to
(we call it project_info),
say project_info contains a version number like "softwareversion =
100", you can increase that number once you are sure that the current
set of files on your disk is what you want to tag for release.
this will increase the revision by one and you have a mismatch if you
do a remote copy of the current wc's revision (svn info).
trunk now has the new revison whereas the revision you want to remote
copy doesn't, trunk might even be 25 revisions higher.
Why not always work on the new revision on trunk and once you are
pleased ,you do a remote copy to tag it to release and mark this as a
finished milestone, after which you can easily increment the
softwareversion in project_info to 101 and start working on version
101 which once pleased with it gets tagged and finished as
version-101. after which you increment the trunk to 102.
the other solution could be to not tag URL/trunk -> URL/tags/release-100
but increment Project-info by one in your Working copy and do a tag
with svn cp WC -> URL/tags/release-100
and afterwards commit the changes to trunk.
I hope that is not too far away from what the original problem was
cheers
cu
christian unger
Received on Mon Jan 22 20:46:10 2007