Jump to content

Get Latest


kevinj

Recommended Posts

I'm a new plastic user so bear with me. I have a workspace and a repository. I have changes in the workspace and somebody has checked into the repository. I'd like to do a 'get latest'/pull from the repository and have the remote changes merged into my local changes. Can I do this?

If I do and update I get the warning dialog. If I choose Continue With Switch I get a warning and if I try and force update I get an error along the lines of 'There aren't new changesets on your current configuration ...' which I'm sure means something important.

So, can I merge remote changes into my workspace without either checking in or undoing local changes?

Thanks,

Kevin

Link to comment
Share on other sites

Hi Kevin!

First of all, welcome to Plastic Community! :D

The best way to go with Plastic is using the branch-per-task lifestyle..

If you need to perform a merge when getting the remote changes, I strongly recommend you perform a local checkin before.

It gives you advantage of having a "safe place" to return if the merge goes wrong.

You can perform a merge even if you have local changes pending, but this is not a best practice (unless you're the team's integrator :) (it means you shouldn't! :P).

The warning you're saying are seeing when performing an forced update is ok. If want to undo your changes, go to the pending changes view and select the files you want to rollback and click in the Undo Changes button! :)

This way you avoid any change of losing any work accidentally! :D

Link to comment
Share on other sites

I understand the branch-per-task model but the project I'm on isn't quite at the point yet. Also, even for this model you may have more than one person working on a task so still have multiple checkins to the same branch that need merging before being sent to the server.

So what is a local checkin and how do I do that? I assume that when I do a checkin my changes are sent to the repository.

It's interesting that you don't consider this best practice (local merge), or am I mis-understanding. My workflow has always been:

Work on local changes - ensure they work

Merge in any changes from the server to the local system - ensure that works

Check in to server

You seem to be advocating:

Work on local changes - ensure they work

Merge in any changes *to* the server *from* the local system

Is this what you recommend?

Kevin

Link to comment
Share on other sites

Hi Kevin!

A local checkin is just a normal checkin made in your local repository.

When someone else performs a checkin in the same branch as you, Plastic handles it beautifully.

There's no problem here. You just need to perform a merge when you think your work is ready to be merged.

I do consider that local merge as a best practice, sorry if I didn't make myself clear about that.

When your co-worker performs a checkin in the workspace (even if it's in the same branch), it will not affect you.

His checkin will be at his repository. You'll never know about that (unless you use the Sync Replication View or via Distributed Branch Explorer).

When you perform a pull request from his machine (or a central server), Plastic will tell you that you have different checkins with the same ID and ask you what to do.

You can perform the merge right now or let this in stand by to perform the checkin later.

It's your call here.

Just one tip: even if you have more than 1 developer working on the same task, you hardly will work in the same things, so there are 2 different sub-tasks which could be in a separated branch :)

Link to comment
Share on other sites

Hi Kevin!

A local checkin is just a normal checkin made in your local repository.

When someone else performs a checkin in the same branch as you, Plastic handles it beautifully.

There's no problem here. You just need to perform a merge when you think your work is ready to be merged.

I do consider that local merge as a best practice, sorry if I didn't make myself clear about that.

I'm still confused. Our current setup is to have a central repository. In that scenario is there a local checkin? or do you mean that I need to have a local Plastic server installed (that leads to a whole bunch of other questions)

When your co-worker performs a checkin in the workspace (even if it's in the same branch), it will not affect you.

His checkin will be at his repository. You'll never know about that (unless you use the Sync Replication View or via Distributed Branch Explorer).

When you perform a pull request from his machine (or a central server), Plastic will tell you that you have different checkins with the same ID and ask you what to do.

You can perform the merge right now or let this in stand by to perform the checkin later.

It's your call here.

I'm guessing that you're assuming a full distributed model where I have a local Plastic server that replicates against a shared server - I don't have that environment, at least at the moment.

Just one tip: even if you have more than 1 developer working on the same task, you hardly will work in the same things, so there are 2 different sub-tasks which could be in a separated branch :)

Right - and back in the real world!

Sorry if that sounds harsh but (in my experience) that's not how development works. For example, if you pair you might be working on one dev's machine one day and the other's the next. Or you might have work and home machines, check into work, check out at home. I need to be able to merge from the server repository to my desktop.

I've used PVCS, Sourcesafe, TFS, Git, CVS and SVN as source control systems over too many years and in all of them (IIRC) I could merge from the server back to my 'workspace'

I'm thinking that my usual source control model/workflow doesn't quite fit into the PlasticSCM mindset and I'm trying to understand the best way of doing what I want to do in Plastic.

Link to comment
Share on other sites

The Update-Commit workflow that you describe isn't exactly how Plastic is setup to work. I'll refer you to this page in the documentation: http://www.plasticscm.com/releases/4.1/manuals-html/en/userguide.htm#_Toc323124591

Basically when you are committing to a branch with other changesets on it after the one you are working on you are going to have to "merge" those changesets in. The "merge now" option would, from my understanding of the documentation and your question, result in exactly what you would want. You would merge those changesets into your workspace first and then check-in. This would result in your work being checked-in at the end of the current branch.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...