Jump to content

Checkin fails if other checkins happen during upload - again and again


Recommended Posts

Some of us can generate large amounts of data changes in a day. When the changes should be checked in it takes so long to upload them that someone else is likely to have made a checkin and the upload is dropped. This results in a manual merge step, even if no conflict exists, and then the whole thing repeats since the data has to be uploaded again. This isn't working well. I see a couple of potential solutions from the client's perspective.

  1. Upload will complete regardless of other checkins but it will stay in a temporary head until merged with the checkin branch.
  2. Checkin will succeed if there's no manual merging needed. This only helps a bit but is perhaps easier to solve.

A workaround (that we wouldn't prefer) could be to submit in a branch since that will always succeed and merge. However, then we get the problem that we can't lock files across branches so we will get merge problems with our binary files instead.

I'm not sure how to attack this problem with Plastic now. Is there something existing today that will solve this situation or will there be something in upcoming releases that will solve it?

Link to comment
Share on other sites

Hi,

Why is it taking so long to upload every checkin? Do you consider using local repos instead (distributed workflow)? I guess you don't because you also use file locks.

  1. Quote

    Upload will complete regardless of other checkins but it will stay in a temporary head until merged with the checkin branch.

    This proposal fits with performing the checkin to a task branch so no conflicts are created and then you can merge the task branch into the main one.

  1. Quote

    Checkin will succeed if there's no manual merging needed. This only helps a bit but is perhaps easier to solve.

    This is the workflow if you use Gluon (partial workspace). But I guess you are using Plastic GUI, right? Because I think using partial workspaces may help.

Regards,

Carlos.

Link to comment
Share on other sites

1 hour ago, calbzam said:

Why is it taking so long to upload every checkin? Do you consider using local repos instead (distributed workflow)? I guess you don't because you also use file locks.

It's taking long because we're working from home due to the pandemic and some of us have poor connections. We're actually not using file locks right now but want to start doing it because we have problems with lots of binary files modified all over the place.

I haven't considered distibuted workflow. I can take a look at it to see if it can be used.

1 hour ago, calbzam said:
  1. This proposal fits with performing the checkin to a task branch so no conflicts are created and then you can merge the task branch into the main one.

It doesn't work with locked file types.

1 hour ago, calbzam said:
  1. This is the workflow if you use Gluon (partial workspace). But I guess you are using Plastic GUI, right? Because I think using partial workspaces may help.

I haven't tried Gluon. Do you mean that partial workspaces will solve this or that Gluon solves the issue by having a better workflow?

Link to comment
Share on other sites

Hi,

Gluon uses partial workspaces. The workspace can load files from different changesets and you will need to resolve a merge conflict only if the same file you are editing has a new revision on the branch. If you re using locks, it should never happen.

In a regular Plastic workspace, the basic unit is the changeset. So when you run a merge, you are merging the full changeset not individual files. By the way, what is your Plastic Client version? Are you using the "Incoming Changes" view?

Regards,

Carlos.

Link to comment
Share on other sites

19 hours ago, calbzam said:

In a regular Plastic workspace, the basic unit is the changeset. So when you run a merge, you are merging the full changeset not individual files. By the way, what is your Plastic Client version? Are you using the "Incoming Changes" view?

The one who had checkin problems recently runs 9.0.16.4361. It must be quite old since I'm on 10.0.16.5338. I don't know if people are using the incoming changes view. I would guess so.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...