Source Project Checkpoint only if no deltas - with trigger?

[ssaul]

Hi,

we would like to do a project checkpoint, but only if there are no member deltas - like for the sandbox snapshot.

I thought this could be done with a trigger.

A server side trigger however does not seem to have access to the sandbox data and so cannot be used.

A client side trigger seems to be much less flexible and powerful.

In addition, I really do not know if there is a checkpoint project client trigger event that can be used.

Does anybody have experience with project checkpoints only if there are no member deltas?

[ssaul]

...what makes things even more complicated:

We would like to allow certain files to have deltas if they have a special attribute set.

[mrump]

Hi Stephan,

The "member delta" in the Sandbox view indicates that a checkin on the working revision would lead to a branch.

This can have 2 different reasons:

1. your Sandbox is out of sync

2. your project is out of sync, meaning, the current member revision is is not the TIP revision

The "member delta" in the project view indicates the same but there is only one reason:

- your project is out of sync, meaning, the current member revision is is not the TIP revision

A checkpoint operation is always a server-side project operation. The checkpoint gives a sh## on any sandbox's content. It simply stores the current project's list of members (and their revision) and sub-projects recursively.

Knowing all this, what exactly is you usecase?

If you want to avoid checkpoints on project configurations that are not "latest and greatest": you can write a sever-side trigger catching the checkpoint PRE-event, that checks the project's content for any member that has a newer revision available, and abort the checkpoint operation if it finds one.

Of course you can extend this trigger for a check on certain member attributes.

But to be honest I do not see a real-live benefit in such a trigger, as it undermines basic functionality of a SCM system.

HTH Matthias

[ssaul]

Hi Matthias,

thanks for your detailed explanation.

Our usecase is that a user has built software from his local sandbox, tested it and now wants to checkpoint it.

A project checkpoint only freezes the member versions, independent on the sandbox content.

A sandbox snapshot freezes the sandbox working files, but only if there are no deltas (otherwise it aborts).

Our user has several local member deltas - for example, generated hexfiles that are also versioned, but also many other files. They have a local delta, no member delta and so this delta is not known to the server.

Project out of sync, meaning, the current member revision is is not the TIP revision is not relevant in this case.

A checkpoint of this project won't reflect the tested version.

A snapshot won't be possible since there are deltas.

I know that it would be much more convenient to tell the user "check in ALL of your files before checkpointing", but with human factor, this will not always be done.

So we had the idea of forcing the user to checkin all relevant files (this is where the attributes come from) before doing a checkpoint.

So we would like to do an extended sandbox snapshot that allows some deltas, but not on relevant files.

Or to do a more restrictive checkpoint that allows some deltas, but not on relevant files.

[tdalon]

Hi Stephan,

if you only want to snapshot the head configuration, you may be interested in following discussion:

http://communities.ptc.com/message/240464#240464

Kind Regards

Thierry

[ssaul]

Hi Thierry,

thanks - that seem to help for member revision deltas, but not for local deltas as our user has.

Best regards,

Stephan

[mrump]

A sandbox snapshot freezes the sandbox working REVISIONS.

Basically it's a batch script that does the following:

1. create a development path from the "nearest" checkpoint of the sandboxes project.

2. reconfigure the development path so it matched the sandbox. This is done by adding/dropping and updating the development path's project members to the sandbox's working revisions.

3. dropping the new development path

So checkpoint and snapshot operations are both server-side, and both can only operate on existing revisions.

Local file changes in a sandbox cannot by stored at all, as long as they are not checked in.

As you correctly said:

...
A snapshot won't be possible since there are deltas.

I know that it would be much more convenient to tell the user "check in ALL of your files before checkpointing", but with human factor, this will not always be done.

So we had the idea of forcing the user to checkin all relevant files (this is where the attributes come from) before doing a checkpoint.

So we would like to do an extended sandbox snapshot that allows some deltas, but not on relevant files.

...

So IMHO you'd need a custom button (aka. script / java tool ) that does the following:

1. Ensure all local changes are checked in:

• use the SI API to find the Working File deltas in the sandbox
  • you can use a filter for your "allow deltas "attribute as well, but the filtered members should be resyncronized
• checkin all these files using option "--noupdate --branch"

2. Snapshot the Sandbox

This cannot be done in trigger.

[ssaul]

Hi Matthias,

so there is no checkpoint project client pre-trigger event (like si.CheckInMembers.pre) that can be used to show deltas or just issue a warning ?

[mrump · Accepted solution]

As far as I know, unfortunately there is no such thing as a client side pre-trigger event at all.

There is a checkpoint pre- event trigger on the server, but that won't fit your needs.

[KaelLizak]

Hello Stephan,

With regards to:

Our usecase is that a user has built software from his local sandbox, tested it and now wants to checkpoint it.

A project checkpoint only freezes the member versions, independent on the sandbox content.

A sandbox snapshot freezes the sandbox working files, but only if there are no deltas (otherwise it aborts).

Are you using change packages? If you are, you could use a trigger to check to see if there are open change packages with uncommitted changes to the project in question, then abort if one is detected. There are some pre- and post-operation client-side triggers, but nothing that would be useful in this content, and as mentioned previously, the server has no concept of client data, so it can't check a sandbox for deltas.

Regards,

Kael

[ssaul]

Hi Kael,

We are using change packages only infrequent, not mandatory, so this might be no real option for us.

Thanks anyways,

Stephan