We are investigating a workflow in Perforce where we create a new temporary branch for every feature project. When projects are stable, they're integrated back into our main branch. Down the line, we would like to remove old project branches from the repository. However I believe this will also delete all revision history for the files modified in the branch. Is it possible to integrate the revision history from the project branches into the main branch?
One solution that I've considered is to manually integrate each individual checkin when merging code back into the main branch. This does not seem like the right approach.
The revision histories as stored against the branch they are applied to, so it is not possible to merge from one to the other. Your idea about integrating each changelist from the project branch will work, but is also a pain as you have pointed out.
I've made extensive use of branching over the years and I can't remember a case where we wished we'd had the branch revision history in the main line or even looked at the branch revision history after the branch was merged back into the main line.
You'll have the revision histories available (though not directly) for a while after a merge and (ideally) anything you check in to the main development branch should pass all the unit tests so the chances of it breaking should be minimised.
First of all, why do you want to remove the branches from the repository? Are you noticing having multiple branches to affecting performance (or expecting it to)? For each 'temporary' branch are you taking an entire copy of the main line? Also why do you consider these branches 'temporary', I would argue if they are for a feature then they are not and should be preserved.
A few articles to read:
- P4 KB Sparse Branching
- P4 Blog: Perforce Anti-Patterns Over-Branching
I believe, without knowing more information, that you could: use sparse branching, make these 'temporary' branches permanent, and if you really have a need for a temporary branch create a private working branch for each of your developers.
Related
This is the situation, how is it possible? I hoped fast forward will prevent, and force to do rebase and have a linear branching.
A fast forward merge is not possible in any case.
In fact, it is only possible if the branch that should be merged to contains no commit that are in the branch you merged from.
You may want to do a rebase merge instead.
Also, the gitlab setting does not change the behaviour of the clients. They can do a normal merge if they want to.
I am working in a project. We use both clearcase and perforce.
As we are working on differnet builds, In clearcase we create a label for each release. Say for release "X", we create a clearcase case "Label X". Label X is having all the latest files with respect to release "X". When we finish another release say "Y", we create another label say "Label Y". Label "Y" is again having all the files for release "Y". But at any point of time we can go back to "Label X" .It means all the files will be reverted back to "Label X".
Can we do same thing in perforce? Can we create a label in perforce so at any point of time, we can go to that label which will give the files as in that label timeline.
Perforce also provide an interesting guide "Migration Planning Guide: IBM Rational ClearCase to Perforce", and mention that p4 label is not the only alternative:
Label Strategies
Both ClearCase and Perforce provide labels, which identify the versions of files that constitute a baseline. For many ClearCase users, labels are mandatory. Applying labels is time-consuming, often accounting for 30 percent or more of the time associated with creating
stable builds.
In Perforce, labels are just one way of reproducing baselines. Changelists accomplish the same goal in ways that are less taxing on the build process and faster and easier to reference than a label.
Each Perforce check-in generates a unique changelist number that reflects the state of the repository at a point in time. Any changelist can be used to describe the state
of every file in the repository, even though it affects only a small subset of the repository.
This is an oversimplication since a typical config spec is several lines or more.
Branches in Perforce are represented as directories, making it easy to combine branches and changelist numbers to represent a baseline.
Alternately, labels can refer to changelist numbers limited to an identified scope in the server, where the scope is typically a particular branch.
Yes, you can create labels in perforce.
Use p4 label to create a label specification, and then use p4 tag to tag files with a label.
You can learn more about labels in the user guide.
Imagine you have the following setup:
//depot/source/sourcefile.cpp
//depot/build/product.exe
At 8am, you check in sourcefile.cpp (now revision 2, in change list 100). The build machine starts building and at 9am, the build machine checks in product.exe, revision 2 in change list 104. Cool. Sadly, you may not have noticed, but at 8:15, someone checked in revision 3 of sourcefile.cpp in change list 103.
What are your options? If you just record the change list of the source (100) and product (104), you can sync your whole project to source and then sync further the contents of change list 104. This process is somewhat manual - you have to record two numbers and do a two step operation.
You can make a label, but sadly, labels don't allow multiple revisions so you it's not really workable.
Finally, at some point after you check in revision 104, you can create a branch. This is basically a metadata copy of the revisions you are interested in so that you can do a one click sync in the future. You can lock the branch to prevent changes.
p4 integ //depot/source/...#102 //depot/milestone1/source/...
p4 integ //depot/build/...#104 //depot/milestone1/build/...
Geeky details - you can configure files in perforce to hold a limited number of revision - for instance you might only want the last 16 revisions of product.exe. (Change the filetype to +S16). If you (or someone else does this), you the first two procedures will eventually fail because the revision has been deleted due to too many revisions. If you use the branch, your product.exe won't age out.
I'm trying to understand if I must use a changelist when I checkout a file?
I'm consider to use Perforce (haven't tried it yet). My question refers to its methodology.
There's a default changelist where things go if you don't specifically choose another changelist for it, but it has limitations like not being able to shelve files. If you're spending a significant amount of time on a change, it's usually very useful to create a numbered changelist with your eventual submit message right away. It's also handy to put temporary changes you don't intend to submit into their own changelist. It's a similar workflow to the way people use multiple local branches in a DVCS.
I am using Subversion with rabbit-vcs on Linux:
Under merge it shows only the option to browse my branches on online svn url
There is no option to give a offline svn folder as branch.
Since, I am pretty new to Subversion, so is it actually possible to merge 2 branches offline on svn ?
I have two branches already checked-out :
/home/user/branch1
/home/user/trunk
First of all, read this. Better yet, read this as well. Arguably, understanding merging is the most important part of knowing how to use SVN correctly (for one, you'll think thousands of times before creating a new branch :) ).
Note that you merge two committed sources into a working copy. That is, even if you specify one of the sources as a working copy it will still take its URL for merge purposes. So this is sort of syntactic sugar that a client may or may not support. The reason for it is that the merge operation needs to identify the common ancestor of the sources and merge them change by change. That information is not present in a working copy.
Note a source for some possible confusion here: in many (most?) instances the working copy argument may specify both a source to be merged and the working copy to merge into).
Here's an example of what I mean: suppose you merge S1 and S2 into W. S1 and W contain file F. S2 does not. Now, there are at least two possibilities: (1) the common ancestor S of S1 and S2 contained the file and it was deleted in S2. Then merge should delete it from W; (2) S did not contain F and it was added in S1. Then F should remain in W. The information about S in simply not present locally, so the repository has to be contacted.
To find out exactly branch URLs your offline working copies come from run svn info in branch1 and trunk.
I tried to merge some work that a developer did in a working branch to a stable branch. The files a, b, and c had been changed by at least a dozen changesets since the common ancestor of STABLE and HEAD branches were separated.
I expected that since this developer changed five lines in each of file a, b, and c, that when I integrated from the HEAD to the STABLE branch, I would get his changes in my pending changset, which I could then review and commit.
Instead, it seems that it has taken every change that happened to file A, since the two were branched, and applied all of those changes that also existed in my colleague's working copy.
In other words, there seems to be no record in a perforce changeset, of what my colleague actually changed, versus what the file before contained.
If I browse the submitted changesets, I can see the difference between my colleague's version of the file, and the immediately preceding version. But then, that does not, it seems, determine what goes into the merge.
Doesn't a changeset mean, "a set of changes made between rev X and revision X+1 of a file"?
Can anybody help me understand what it means to "integrate a changeset" when in fact, what it seems is that Perforce doesn't track changes, it tracks files.
It is entirely possible that I am doing everything wrong, and would appreciate any pointer as to how it is that you can can merge accurately and safely between Perforce working branches and stable branches, without stuff that you don't want to get integrated to the stable branch getting integrated. It seems that no matter how simple the changes that actually get made in the product, the merge does not actually work for me.
Perforce does save changes to text files as deltas (binary files get saved in their entirety every time a change is submitted). It sounds like you're not properly restricting the revision range during your integration.
You say the working branch has "...been changed by at least a dozen changesets since the ...branches were separated." Let's call them changelists 1-12. If I understand you correctly you are trying to integrate the modifications made in just one of those changelists, not all of them.
During a simple integration operation Perforce will assume you want to integrate all of the changes that have been submitted since the branch was made. If you only want a subset of these changes, you have to specify a revision range. So, if you just want to integrate the changes that occurred between changelist 11 and 12, you would specify that revision range as shown in the screen capture. (Note: the revision range is inclusive, so specifying a range of 11-12, as I do in this screen shot will actually include changes in changelists 11 and 12. If you just want to integrate the changes made in changelist 12, enter 12 in both fields of the revision range.)
Just be aware that the inevitable conflicts that arise may be difficult to resolve, depending upon how far the branches have diverged and the nature of the changes.
Could you be more specific on how you did the integration? My guess is that you probably have integrated all the changes up to that changelist instead of just that changelist only. If so all you need to do is to specify the same changelist as both the upper and lower limit of the integration.
It's very easy to do in the visual client, but I'm not sure of the exact command line switch you need to use.