"Catalin Marinas" [off-list ref] writes:
On 13/12/2007, David Kågedal [off-list ref] wrote:
quoted
I have a fair amount of branches, and I noticed that "stg branch -l"
takes ridiculously long to finish.
I have the same problem.
quoted
Maybe someone can help me find a quicker replacement for the
get_protected call?
Hey, why not put the "protected" flag in the config? Then we can get
it the same way as the other stuff.
Protecting a branch is a configuration action, so it makes sense to
put it in the config.
--
David Kågedal
On 13/12/2007, David Kågedal [off-list ref] wrote:
"Catalin Marinas" [off-list ref] writes:
quoted
On 13/12/2007, David Kågedal [off-list ref] wrote:
quoted
I have a fair amount of branches, and I noticed that "stg branch -l"
takes ridiculously long to finish.
I have the same problem.
quoted
Maybe someone can help me find a quicker replacement for the
get_protected call?
Hey, why not put the "protected" flag in the config? Then we can get
it the same way as the other stuff.
Protecting a branch is a configuration action, so it makes sense to
put it in the config.
Yes, I'm OK with this. The only problem I see is that we have to
change the stgit.formatversion and provide an upgrade in the Series
object. However, 'stg branch -l' no longer initialises the Series
objects and the upgrade won't happen.
The branch command would have to check format version and force the
upgrade if it isn't the required one.
BTW, have you run stg-prof to check where it spends most of the time?
Is it caused by Python object creation or GIT calls invoked during the
Series objects initialisation. If the latter, we can turn some
variables into properties and access them lazily.
--
Catalin
On 2007-12-13 15:31:24 +0100, David Kågedal wrote:
Hey, why not put the "protected" flag in the config? Then we can get
it the same way as the other stuff.
Protecting a branch is a configuration action, so it makes sense to
put it in the config.
I agree; if we are to have such a flag, the config is the right place
for it.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle