Temporarily restrict deliveries to a stream?
Is there a way to temporarily restrict deliveries to a stream during our (lengthy) build process? (Note that the build is using the SCM commandline for fetching and delivering - we are not using build engines or anything else)
RTC makes this better than our previous VSS setup, in that if a changeset is delivered during the build process, since the Accept and Load into the build workspace has already happened, the final baseline with the build changeset can be delivered without a problem; and the other changesets just appear "after" the baseline. Great.
However, if someone modifies a file that is also modified by the build process, that's going to create a conflict and break the delivery.
So, the simplest solution would be a temporary block on delivering changesets (except for some users) that could be easily switched on and off (preferably from the command line, but manually will do for now!)
Is this possible?
This looks as though it might help, but I don't seem to have a "Restrict change set delivery to components in a stream" precondition to use.
Thanks in advance for any assistance!
RTC makes this better than our previous VSS setup, in that if a changeset is delivered during the build process, since the Accept and Load into the build workspace has already happened, the final baseline with the build changeset can be delivered without a problem; and the other changesets just appear "after" the baseline. Great.
However, if someone modifies a file that is also modified by the build process, that's going to create a conflict and break the delivery.
So, the simplest solution would be a temporary block on delivering changesets (except for some users) that could be easily switched on and off (preferably from the command line, but manually will do for now!)
Is this possible?
This looks as though it might help, but I don't seem to have a "Restrict change set delivery to components in a stream" precondition to use.
Thanks in advance for any assistance!
One answer
The "Restrict change set delivery to components in a stream" is probably
the best process oriented way to achieve your goal, but the SCM command
line does not expose process related stuff, so you'll have to continue to
do it manually.
The SCM command line can use 'lock acquire/release' to lock individual
files in a stream; however that might not be appropriate if you're
planning to lock down the entire stream. It's design was more for
individual users who are locking individual files that they are editing.
If you're talking about locking only a handful of files, then this
solution may work for you.
Just some questions and ideas about your setup. (I'm not trying to judge
your workflow, maybe your setup needs to be this way).
-Why is it that there are some artifacts that both the build and users
might touch? I've always thought of build artifacts as always being
derived artifacts. So users never touch them. And source always being
edited by users, so the build never touches them.
-Would it be better if the build did not deliver to the same stream as
users and there be a separate integration step? Maybe the build can
deliver to a separate stream to track its generated snapshots while users
deliver to a user stream. If there are no conflicts maybe integration can
be automated?
-Is a long build going to prevent users from working if the stream is
locked down? Those users are likely going to need to merge anyways then.
On Tue, 15 Sep 2009 06:38:03 -0400, DuncanL
<duncan> wrote:
--
the best process oriented way to achieve your goal, but the SCM command
line does not expose process related stuff, so you'll have to continue to
do it manually.
The SCM command line can use 'lock acquire/release' to lock individual
files in a stream; however that might not be appropriate if you're
planning to lock down the entire stream. It's design was more for
individual users who are locking individual files that they are editing.
If you're talking about locking only a handful of files, then this
solution may work for you.
Just some questions and ideas about your setup. (I'm not trying to judge
your workflow, maybe your setup needs to be this way).
-Why is it that there are some artifacts that both the build and users
might touch? I've always thought of build artifacts as always being
derived artifacts. So users never touch them. And source always being
edited by users, so the build never touches them.
-Would it be better if the build did not deliver to the same stream as
users and there be a separate integration step? Maybe the build can
deliver to a separate stream to track its generated snapshots while users
deliver to a user stream. If there are no conflicts maybe integration can
be automated?
-Is a long build going to prevent users from working if the stream is
locked down? Those users are likely going to need to merge anyways then.
On Tue, 15 Sep 2009 06:38:03 -0400, DuncanL
<duncan> wrote:
Is there a way to temporarily restrict deliveries to a stream during
our (lengthy) build process? (Note that the build is using the SCM
commandline for fetching and delivering - we are not using build
engines or anything else)
RTC makes this better than our previous VSS setup, in that if a
changeset is delivered during the build process, since the Accept
and Load into the build workspace has already happened, the final
baseline with the build changeset can be delivered without a problem;
and the other changesets just appear "after" the baseline.
Great.
However, if someone modifies a file that is also modified by the
build process, that's going to create a conflict and break the
delivery.
So, the simplest solution would be a temporary block on delivering
changesets (except for some users) that could be easily switched on
and off (preferably from the command line, but manually will do for
now!)
Is this possible?
This looks as
though it might help, but I don't seem to have a
"Restrict change set delivery to components in a stream"
precondition to use.
Thanks in advance for any assistance!
--