P42RTC Learning to think about changesets

I've been reviewing some documentation on changesets, and trying to make sure that I have the idioms straight in my head. I'm coming from using Perforce, and presumably will be making some errors in that direction, which I hope you will be kind enough to correct.

Hi Danil

I will have a go - and I am sure others will correct as required. You should definitely read some of the articles in the library on SCM - they will express the concepts much more eloquently than I can - and have pictures too!

In this specific exercise, I want to walk through a developer committing and integrating their first change with the rest of the team.

To begin, I assume that the developer has created his own private workspace in the repository, flowing with the appropriate stream.

So first thing is to think of three spaces you will be working with: the local workspace on your disk, the repository workspace on the server (a mirror of what is on your local workspace), and the stream where you are going to share everything.

So first he needs to load his repository workspace into his local workspace. That means that load is roughly comparable to a sync (pretending for the moment that the developers repository workspace is kin to a p4 branch).

So Load pulls the files from the Stream into the repo and local workspace (you don't have to pull right through but let's assume you do). I suspect the repo workspace is like a branch - but I don't know p4.

He can then edit any of the local copies of his file. He can do this immediately; there's no explicit checkout required, and that repository listeners cannot yet detect that he is working on a file. Saves to the local copy of the file(s) may be made as he likes, with each save completely overwriting his previous local copy.

Almost. No explicit checkout - spot on. The people working off the Stream on their repo and local workspaces are unaware of the potential changes - apart from the terminology - you are right again. However, the local saves are part of the local history, so while it overwrites the local files, you can go back to previous saves.

The developer at his discretion can checkin the changes to one or more files. This operation doesn't really exist in p4, as we aren't yet actually committing a version of the file anywhere. It's somewhat like a checkout (implicitly or explicitly assigning a file to a changeset, restricting the developers ability to add that file to other changesets), and a repository save: now repository listeners can know that the file is being worked on, and the most recent copy of the work can be consumed by other repository listeners (jbe, for instance). It differs from a perforce submit in that you won't be able to recover this change if it is later overwritten.

Hmm - so the checkin is more like "copy-to-the-server-to-my-repo-workspace". The changeset comes in because the files that have been changed with become part of the current changeset. You can then close out the changeset (Complete) or continue to add more changed files until you want to go to the next stage and Deliver. If you do Complete the changeset - you can now make new changes and those will be for a new changeset.

Until you actually do a Deliver - no-one knows you have changed the file(s).

After a change has been checked in, the user can move the file between open change sets, much as a p4 user can move files between open changelists.

When a changeset is completed (the command line spelling appears to be close), now there's a real version mark in place, and you have way to get back to this specific version of the file. The file is also available again to be added to open change lists. It appears that this is the close match to the submit command in perforce.

I am not quite sure how to compare this moving files between changelists to changesets, so let me skip this bit for the moment.

Finally the developer can deliver one or more changesets to another stream or workspace. Any open changesets made part of the delivery will be implicitly completed. Once the change sets are all completed, the rest of the operation is similar to a p4 integrate, it seems to me.

OK - so now we do the Deliver - this moves the changes into the Stream and everyone whose repo workspaces flows to that stream will be told that these files have changed. They will see Incoming changes in the Pending changes view, and Eclipse decorates the files in the various Explorers. They can either stop what they are doing, reconcile and accept those changes, or ignore them for the moment. They could even ignore them totally and switch to another stream and Deliver there but we are jumping ahead of ourselves.

You generally Deliver to a Stream, not often to another repo workspace (you are king - or queen - of your own local/repo workspace - no-one can forces changes on you). As you suggest, changesets are automatically completed.

How'd I do - anybody want to offer obvious corrections?

Thanks.

Hope that helps somewhat.

Keep asking questions - we do have other p4 users (or people with p4 experience) on this forum, perhaps they can add to this too.

regards

anthony

Thanks kesterto...

So Load pulls the files from the Stream into the repo and local workspace (you don't have to pull right through but let's assume you do). I suspect the repo workspace is like a branch - but I don't know p4.

If others can't see completed changesets in your workspace, then it certainly isn't a branch.

However, the local saves are part of the local history, so while it overwrites the local files, you can go back to previous saves.

The local history is available only if you've been performing the edits within eclipse?

Thanks kesterto...

So Load pulls the files from the Stream into the repo and local workspace (you don't have to pull right through but let's assume you do). I suspect the repo workspace is like a branch - but I don't know p4.

If others can't see completed changesets in your workspace, then it certainly isn't a branch.

However, the local saves are part of the local history, so while it overwrites the local files, you can go back to previous saves.

The local history is available only if you've been performing the edits within eclipse?

No problem.

OK - so not a branch then. The Stream sounds like a branch.

Local history is a function of Eclipse. I would need to check if Visual Studio has something similar. I don't believe this concept exists in the commandline, it is more an IDE function we take advantage of.

anthony