StarTeam Revisions & Labeling

Hello Lee,

Time resolution in StarTeam is seconds. Theoretically, there is a probability
of occurance of points 2 and 3 within the same second, but I think you can
safely neglect it.

In any way, since StarTeam doesn't support whole repository revisions (like
Subversion, for example) the probabilty exists even if you manually run the
scenario you described without TeamCity (unless you attach specific revisions
of each item to the label). So TeamCity doesn't make things worse. :)

Hello folks,

I understand that TeamCity labels after the build - and this is great,
it allows us to only label if a build was successful and allows us to
label any historical build that TeamCity is aware of.

What I am wondering about is StarTeam's revisions. As far as I
understand it, the StarTeam revision is a timestamp.

When we label based on a timestamp is this necessarily accurate
enough?

It is conceivable that multiple people could commit changes at the
same instant.

I don't know the resolution of the StarTeam revision timestamp, is it
seconds?

Example scenario, within the same second in the following temporal
order:
1) Bob commits changes to StarTeam
2) A build is initiated by TeamCity.
3) Mary commits changes to StarTeam.
Let's assume that the build iniated by TeamCity includes only Bob's
changes. It runs successfully. When we use TeamCity to label the
build via timestamp, could it also (incorrectly) include Mary's
changes?

Much thanks for clarifications,

-Lee-

---
Original message URL:
http://www.jetbrains.net/devnet/message/5232513#5232513

--
Sergey Anchipolevsky
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Thanks for your reply Sergey,

It is unfortunate that StarTeam does not support whole repository revisions.  Do other VCS systems share this deficiency?

Accurate reproducible builds are essential.  I know that the the scenario I describe is unlikely, but because it can happen, it will happen.  My people are a serious bunch, I expect that will not be crazy about this.

When creating an official build, our current manual process is:

1. Label
2. Checkout from label
3. Build
   

But I am thinking that pre-labeling might not be necessary: A couple of ideas:

1. If TeamCity were to always fetch from StarTeam 1 second prior to the latest StarTeam revision, might this be a work-around to the problem for StarTeam?  This way, theoritically, TeamCity would never fetch only part of a revision.  This assumes that the StarTeam server clock always progress forward - if we increase this to 10 seconds in the past, this would be more than enough to account for any NTP syncing on the StarTeam server.
   
2. Also any Changes that share the same StarTeam revision would have to be grouped.  A TeamCity user would not be able to act upon changes that fall under the same StarTeam revision independently.
   

What do you think?

-Lee-

Hello Lee,

See my answers inline

Thanks for your reply Sergey,

It is unfortunate that StarTeam does not support whole repository
revisions. Do other VCS systems share this deficiency?

Yes. A lot of. It's simpler to list those supporting it:

Subversion, Perforce, GIT, Mercurial, TFS and maybe a couple of others.
Global versioning is a relatively modern feature, and older version controls
like CVS or VSS dont support it.

Accurate reproducible builds are essential. I know that the the
scenario I describe is unlikely, but because it can happen, it will
happen. My people are a serious bunch, I expect that will not be
crazy about this.

We creating an official build, our current manual process is:
1. Label
2. Checkout from label
3. Build
But I am thinking that pre-labeling might not be necessary: A couple
of ideas:

1. If TeamCity were to always fetch from StarTeam 1 second prior to
the latest StarTeam revision, might this be a work-around to the
problem for StarTeam? This way, theoritically, TeamCity would never
fetch only part of a revision. This assumes that the StarTeam server
clock always progress forwar

d - if we increase this to 10 seconds in the past, this would be more
than enough to account for any NTP syncing on the StarTeam server.

This is an interesting idea. Thank you for suggesting.
It needs a careful thinking over, though. Wouldn't you like to create a new
issue?

2. Also any Changes that share the same StarTeam revision would have
to be grouped. A TeamCity user would not be able to act upon changes
that fall under the same StarTeam revision independently.

If you mean grouping changes into change-lists it's already done in TeamCity.
StarTeam plugin groups changes into a single change list if they have the
same commiter, comment, and close modification timestamps.

What do you think?

-Lee-

---
Original message URL:
http://www.jetbrains.net/devnet/message/5232572#5232572

--
Sergey Anchipolevsky
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Thanks for your reply Sergey,

Yes indeed, the StarTeam seconds-based revision scheme is a nuisance.

2. Also any Changes that share the same StarTeam revision would have
to be grouped.  A TeamCity user would not be able to act upon changes
that fall under the same StarTeam revision independently.

If you mean grouping changes into change-lists it's already done in TeamCity.
StarTeam plugin groups changes into a single change list if they have the
same commiter, comment, and close modification timestamps.

Yep, I was thinking of the change list (but maybe there are other areas in the TeamCity too?). I'm sure you'll set me straight if I've misunderstood how TeamCity works, but because of StarTeam's second-based revisioning scheme if our grouping key is committer+comment+close modification timestamp, then maybe we have a problem?  If Mary & Bob have the same close modification timestamp (effectively the StarTeam revision?), then I think that TeamCity might have to only allow actions on this group of Mary's+Bob's changes because they share the same StarTeam revision.  For example if I try to label only Bob's changes, I'll end up also labelling Mary's.  If I want to build from Bob's changes, won't the build also include Mary's changes?

-Lee-

Hi Sergey,

This is an interesting idea. Thank you for suggesting.
It needs a careful thinking over, though. Wouldn't you like to create a new
issue?

I have created a new issue: http://www.jetbrains.net/tracker/issue/TW-7296.

Thanks,

-Lee-

Hello Lee,

Thanks for your reply Sergey,

Yes indeed, the StarTeam seconds-based revision scheme is a nuisance.

>
>
>> 2. Also any Changes that share the same StarTeam revision would have
>> to be grouped. A TeamCity user would not be able to act upon changes
>> that fall under the same StarTeam revision independently.
>>
> If you mean grouping changes into change-lists it's already done in
> TeamCity.
> StarTeam plugin groups changes into a single change list if they have
> the
> same commiter, comment, and close modification timestamps.
>

Yep, I was thinking of the change list (but maybe there are other
areas in the TeamCity too?). I'm sure you'll set me straight if I've
misunderstood how TeamCity works, but because of StarTeam's
second-based revisioning scheme if our grouping key is
committercommentclose modification timestamp, th

en maybe we have a problem? If Mary & Bob have the same close
modification timestamp (effectively the StarTeam revision?), then I
think that TeamCity might have to only allow actions on this group of
Mary's+Bob's changes because they share the same StarTeam revision.
For example if I try to label

only Bob's changes, I'll end up also labelling Mary's. If I want to
build from Bob's changes, won't the build also include Mary's changes?

You're right. If Bob's change have the same repository revision as Mary's
change you won't be able to make a build with only one of them using the
standard TeamCity approach.

Again the probability of that is VERY low. I don't want to say it's impossible,
but even if it happens someday AND if you really want to split those changes
into separate builds (these two conditions must concur :), you can manually
attach corresponding files revisions to different labels and make separate
builds using these labels.


Sergey Anchipolevsky
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Thank you, Lee :)

I have created a new issue:
http://www.jetbrains.net/tracker/issue/TW-7296.

--
Sergey Anchipolevsky
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Hi Sergey,

Guest wrote:

Hello Lee,

Thanks for your reply Sergey,

Yes indeed, the StarTeam seconds-based revision scheme is a nuisance.

>
>
>> 2. Also any Changes that share the same StarTeam revision would have
>> to be grouped.  A TeamCity user would not be able to act upon changes
>> that fall under the same StarTeam revision independently.
>>
> If you mean grouping changes into change-lists it's already done in
> TeamCity.
> StarTeam plugin groups changes into a single change list if they have
> the
> same commiter, comment, and close modification timestamps.
>

Yep, I was thinking of the change list (but maybe there are other
areas in the TeamCity too?). I'm sure you'll set me straight if I've
misunderstood how TeamCity works, but because of StarTeam's
second-based revisioning scheme if our grouping key is
committercommentclose modification timestamp, th

en maybe we have a problem?  If Mary & Bob have the same close
modification timestamp (effectively the StarTeam revision?), then I
think that TeamCity might have to only allow actions on this group of
Mary's+Bob's changes because they share the same StarTeam revision.
For example if I try to label

only Bob's changes, I'll end up also labelling Mary's.  If I want to
build from Bob's changes, won't the build also include Mary's changes?

You're right. If Bob's change have the same repository revision as Mary's
change you won't be able to make a build with only one of them using the
standard TeamCity approach.

Again the probability of that is VERY low. I don't want to say it's impossible,
but even if it happens someday AND if you really want to split those changes
into separate builds (these two conditions must concur :), you can manually
attach corresponding files revisions to different labels and make separate
builds using these labels.

I agree that the probability is low for projects with a few developers, but when you get into projects with many developers the probability increases. If it can happen, it will happen and when it does happen it will have a negative impact.

My thinking is that repeatable and consistent builds are essential - especially for release builds.  I would prefer that TeamCity only allow me to only manipulate my VCS at the granularity of the VCS's revision. 

I expect that a warning might be a good first step: If I am about to performan an operation on Bob's change set, TeamCity could first warn me that my operation will also include Mary's change set before proceeding with the operation.

-Lee-

Hello Lee,

I agree that the probability is low for projects with a few
developers, but when you get into projects with many developers the
probability increases. If it can happen, it will happen and when it
does happen it will have a negative impact.
My thinking is that repeatable and consistent builds are essential -
especially for release builds. I would prefer that TeamCity only
allow me to only manipulate my VCS at the granularity of the VCS's
revision.

I totally agree with you in respect of repeatable builds.
You suggestion with a time lag would seem to be a good solution to this problem.

I expect that a warning might be a good first step: If I am about to
performan an operation on Bob's change set, TeamCity could first warn
me that my operation will also include Mary's change set before
proceeding with the operation.

If by "operation" you mean building a historical build upon a particular
change-list, then I agree such a warning would be useful. Or, perhaps, just
listing all change-lists that are supposed to be included into this build.
I think this is worth adding a change request into our tracker. :)


--
Sergey Anchipolevsky
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Hi Sergey,

If by "operation" you mean building a historical build upon a particular

change-list, then I agree such a warning would be useful. Or, perhaps, just
listing all change-lists that are supposed to be included into this build.
I think this is worth adding a change request into our tracker. :)

Although I am becoming familiar with TeamCity, I am by no means an expert.  The two operations I noticed that can be invoked on history are:
1) build - at the individual change level.
2) label - at the build level.

I have referenced this thread in my initial tracker entry.  I think it is all related.

Thanks for all the discussion and interest, I appreciated it,

-Lee-