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.
Related
I have two branches (A and B). I changed several files in A and made a backout. When I integrate A to B also these files appear, even nothing has changed (besides files with real changes). How can I avoid that?
B is the main branch for several other branches, so for the next time a lot of integrations with several files without changes would be integrated across the depot. Any help appreciated.
I'm not sure if I'm correctly understanding you when you say "made a backout" because you also say "nothing has changed" -- usually "backout" implies making a change (i.e. you made changes that are the inverse of earlier changes).
In either case though, if when integrating A to B you do not want your changes made in A to have any effect on B, and you do not want those changes to be candidates for integration into B in the future, resolve with "-ay" (accept yours, where "yours" is the set of files you're modifying, i.e. B), and then submit. This will create a new revision which records that B is ignoring these changes in A.
I maintain a family of branches, .../base/..., .../base-staging/..., .../base-production/.... Changes are usually made in base, reviewed, and then integrated out to base-staging and eventually base-production. Before an integration, I typically do a p4 interchanges to confirm that only expected changes will be carried forward.
Usually this works. But sometimes p4 integrate pulls over files and changes not listed by p4 interchanges. By my understanding, that shouldn't happen! What am I misunderstanding?
Details:
Ancient history:
create .../base/...
p4 integrate base/... base-staging/...
p4 integrate base/... base-production/...
make changes in .../base/... and submit
p4 interchanges base/... base-staging/...
review and approve
p4 integrate base/... base-staging/...
whoah! what are all these other listed files???
review: real changes, made well before my interchanges command, but not mentioned therein
I'm going to assume we're talking about a relatively recent server release -- on older releases "interchanges" will indeed match exactly what "integrate" lists, but in newer releases they diverge a bit in order to address the subtly different common use cases of the two commands.
One of the functions of "integrate" is to record history that ensures that future integrates behave in a predictable fashion. In some edge cases that means opening a file for integrate even though no actual changes need to be propagated to the target, so that it can be recorded that the file is up to date. A very simple example: make a change in A, ignore from A to B, merge from B to C, now merge A to C. Your expectation will typically be that integration is "transitive" such that if A->B reports nothing to do and B->C reports nothing to do then A->C will report nothing to do; if the B->C merge skips the change because it was an "ignore", though, then the A->C merge has no record that the B->C merge was ever even attempted, and it will propagate the change, violating the expectation of transitivity.
"Interchanges", however, does not record any history, and it is usually desirable for it to limit its scope to report only source changes that are not present in the target. It's therefore tuned to produce a smaller set of changes than you might get by running "integrate". The changes that are excluded from "interchanges" but included by "integrate" are typically going to be ones that do not strictly require merging, but that will probably make it easier to merge the "required" changes if they're included as well.
Using the "-Rs" flag on "integrate" will cause it to mimic the "interchanges" behavior and select the absolute minimum set of source revisions. It's briefly described in this old blog post from when it was introduced:
http://www.perforce.com/blog/101206/p4-integ-3-exciting-things-afoot
After deleting my Svn repo by accident the other day I wanted to try something else and I have chosen Perforce as my current versioning tool testing ground. It is going great and I am liking what am seeing in Perforce.
Here is my problem. I have submitted my files to my Perforce server and then used my client pcs to grab those projects from the master Perforce server. Now all works great except that I realized that it is possible to use more than a single "depot" in Perforce, and it makes sense to me that I should just move some of those projects to another depot fpr the sake of organization and and maybe for security reasons inn case.
I have been looking for some answers, and I have found couple of them however I am unable to produce any intended results thus I am looking for some expert advice here.
One of the pages I have tried is this one
http://kb.perforce.com/article/24/renaming-depot-directories
Seems to offer a solution, however I have not been able to move files from one depot to another depot that is on the same server process. The examples in the page works fine for moving some folder to a folder in the same depot. The example seems to demonstrate moving to another folder under the same depot.
So I am looking for a reasonable and safe way to move my master Perforce depot folders to another depot that is on the same server, and naturally without loosing any work.
Here is what I am wanting
-- Current
//Depot-A
-->folder1
-->folder2
-- I want
//Depot-A
-->folder1
//Depot-B
-->folder2
thanks
Moving files between different depots is no different than moving files between folders within the same depot, with the exception that the target depot must already exist. Using your example, and assuming "Depot-B" doesn't exist yet, to move "folder2" from "Depot-A" to "Depot-B", you would simply do this:
p4 depot Depot-B
p4 edit //Depot-A/folder2/...
p4 move //Depot-A/folder2/... //Depot-B/folder2/...
p4 submit
Here's what I would do (in a nutshell): If you open a P4V session and select the submitted changelists tab, you can filter this set to show only the changes that relate to the section you want to move. This is the change set you will duplicate on the new depot (or even server) that you want to populate. The idea is that you are unraveling the archive files on one side and winding them up in the identical way at the destination. So the process is simply (1) syncing to the first changelist, (2) integrating that set across to the new location, (3) checking that set in, and (4) proceed to the next changelist. Obviously this can be scripted. I am currently in the process of working a script up in python, but any decent scripting language with Perforce function libraries will work. A couple of complications: The changelists will be sequentially the same as the originals, but the original times will not - they will be "current". And of course if there are labels, you'll need to map that out in the new location if you want them preserved.
I don't think additional depots add much in the way of security. Multiple depot scenarios primarily arise in very large installation.
The primary benefit of additional depots is that you can gain more control over the disk space layout of your server, for example if your repository is too large to fit onto a single filesystem and you need to expand it to use multiple filesystems. A secondary reason to create additional depots is if you have to have depots of specialized types; for example if you wish to create a Streams depot to use the Perforce Streams feature.
For a scenario such as the one you describe, having all your files under Depot A is probably fine for the foreseeable future.
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.
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.