Hi Jan,
Jan Holesovsky wrote:
Hi Heiner,
On Wednesday 26 August 2009, Jens-Heiner Rechtien wrote:
Everyone using a mercurial based CWS MUST enter the new milestone in EIS
manually after rebasing the CWS to a new milestone using mercurial
commandline or gui tools.
Cannot this be automated?
With git, all you'd need is to have a post-update hook on the server that
does 'git describe' (finds the most recent tag that is reachable from a
commit) on the CWS, and just gives the tag to the EIS. I suppose the
same must be achievable with Mercurial, right?
Yes, something like that is possible with hg.
Great!
But it's somewhat wrong
also because in most cases it's more relevant what's in your local
working repository and that might be much more current than what you
have in the outgoing rep.
I don't think it is wrong. In your local repository, you don't care about the
milestone at all, it is important for the outside world only. From the other
mail:
----- 8< -----
Thus in order to not break processes which depend
on the correct milestone version information in EIS like buildbots or
automated tests do for example a developer MUST update milestone
information in EIS manually after using mercurial tools to update the
source code to the new milestone.
----- 8< -----
The buildbots and the automated tests will never get what you have locally,
unless you push that. So from my understanding, the information in the EIS
should track what is published (pushed) => post-update hook is what we want.
So the whole notion of the "current milestone" is somewhat unclear in a
DSCM scenario.
No, the notion of the current milestone is perfectly defined - the most recent
tag that is reachable from the commit. What is somewhat unclear in the DSCM
scenario is the definition of Child workspace :-) - is the CWS what is on the
server, or each and every clone out there? Is every clone the one CWS, or is
it several CWSes? ;-)
Heretic idea comes to my mind - what about to discard the 'current milestone'
info from EIS completely, and update buildbots/automated tests/etc. to count
the 'current milestone' themselves using the Mercurial equivalent of 'git
describe'? Then we never can be wrong, and the info can never be
outdated/out of sync.
Haven't thought finally about it. There will be at least a command line
method to update the milestone.
The rebasing using the Mercurial tools only is a great leap ahead [thanks for
that!], let's not make a step back by introducing commands that are not
really necessary...
I'll keep that in mind. Some great suggestions here, I'll have a look at
them!
Regards,
Heiner
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
