Currently, I am working with an svn repository with a slightly unconventional layout. There are two directories where branches may appear. For example:
Project/
Foo/
A/
B/
C/
Support/
Branches/
taskbranch1/
taskbranch2/
taskbranch3/
taskbranch4/
Tags/
In this layout, there isn't really a designated "trunk". Each of the directories "A", "B", and "C" are branches, in the sense that they represent ongoing development of multiple versions of the same product, and they are the closest thing to a "trunk" for the developers working therein.
Branches/
contains more traditional, task-oriented branches (i.e. they are typically short-lived and are merged back into A, B or C and deleted when the task they represent is completed)
When working in git, I'd like git to treat the children of "Foo" and the children of "Support/Branches" as branches. However, the wildcards allowed in the svn-remote.branches setting don't seem to be expressive enough to allow this.
In the past, I've set up several different git repositories (one each for A, B and C), with the same svn URLs for tags and branches, however, that seems wasteful, as the vast majority of the contents of those three repositories will be identical.
When you run git svn clone or git svn init you can use the --branches (and --tags) options more than once to specific multiple locations for branches (and tags).
What this does is create multiple svn-remote.<name>.branches settings in the config. This should work correctly instead of trying to use a single svn-remote.<name>.branches setting that matches both locations.
Related
I'm working on a (GNU/Linux) system with a ClearCase client installed. On this system, people don't always have views correspond to every branch; and have different "branch trees" for different files.
Now, given that I have no relevant view set as the present working view, or that the PWV is irrelevant to the branches I'm interested in - how do I generate a diff between the files existing on two specific branches?
In this question:
https://stackoverflow.com/a/2786120/1593077
there are assumptions about the PWV being relevant, I believe.
One simple way would be to create two snapshot views dedicated for that task:
one with a config spec selecting branch1
one with a config spec selecting branch2
Then a Linux tool like kdiff3 (or at least a simple diff -qr dir1 dir2) would display the difference between files list and file contents.
How to prevent checking out / changing one binary file in different branches of the same content. Situations like: designers have edited some game level (*.umap binary file) in their branch. Programmes changed same file in their branch (for example - added some blueprint on this game level). So now we have three different versions of this file, one in master branch before all changes, one in designers branch without programmes changes, one in programmes branch without designers changes. And now we must merge designers changes and programmes changes into master branch, but we cant.
So the question is - how to organise right this situations? Maybe we can setup perforce to checkout binary file in multiply branches at the same time, or something like this? Thanks...
There are a couple of different ways to think about this.
If you don't want work to continue/begin in one branch, until changes from another branch have been merged in to it, you can use Helix (Perforce) Protections, to give users read-only access to the branch.
This means they will be able to open files for edit, but won't be able to submit their changes.
More info about protections is here:
https://www.perforce.com/perforce/doc.current/manuals/p4sag/chapter.security.html
The protections would need to be changed, when you are ready for work on the other branches to start.
If you want a file to be automatically checked out on all branches, each time someone checks it out on any branch where it exists, you would currently have to script this.
You could do it using the broker and a workspace for every branch, that has a view that just includes the files you want to be checked out everywhere.
The files would then need to be checked out in these workspaces and locked, so that other users can't submit to these branches until the locks are removed.
This is not trivial and may have a performance impact.
You might also be able to do it using pre-command triggers, if your server version is new enough.
If you want to go in to more detail about any of the above, I recommend you contact Perforce Technical Support.
Hope this helps,
Jen.
We already have dspace installed in various institutions across the country and want to deploy a centralized DSPACE repository as part of the federated repository. Contents from the branch repository will be synced to the centralized repository as soon as they are published. Contents from the centralized repository are then synced back to other branch repositories. Contents are not synced directly between branch repositories but only through the centralized repository.
Please we welcome ideas on how to achieve this as while we have various references including http://www.dlib.org/dlib/july06/tansley/07tansley.html and http://link.springer.com/chapter/10.1007/978-3-642-40276-0_21, we cant seem to make any headway.
For the first part of the puzzle, pulling the contents of your branch repositories into the central one, you could look at this feature:
https://wiki.duraspace.org/display/DSDOC5x/XMLUI+Configuration+and+Customization#XMLUIConfigurationandCustomization-HarvestingItemsfromXMLUIviaOAI-OREorOAI-PMH
The second challenge, having the branch repositories pull back changes/or new items from the central one, is quite another thing.
Unidirectional integrations where one repository is clearly the master record for a particular item is quite straightforward. However, bidirectional updates and managing the different cases and edge cases around changes happening in multiple places to the same items, is a big challenge.
So basically I'm advising you to reconsider your strategy and check if a scenario where one repository is always the master record for a particular item would also fit your use cases.
I am looking for best practices using branches in RCS.
I had read the man page for rcs and ci and also browsed at the following links:
http://www.gnu.org/software/rcs/manual/html_node/Concepts.html
http://www.gnu.org/software/rcs/manual/html_node/Quick-tour.html
Suppose i have revision 1.3 on tip of the trunk.
I now want to change file 1.2 (as 1.3 have several other changes I cannot yet use).
I understand I can create branch on revision 1.2 using ci -r1.2.1
My question are the follows:
1. Do I need to set a lock on the file? If so, on which revision?
2. If no lock set, I cannot use -u flag in order to keep the file in my local dir. In case I wish to do so, is it still possible without co the file again?
Side note: I feel RCS does not suit my company needs however migrating to another system is not my decision to make, so currently I need to keep working with it.
I'm looking for much the same thing, but seeing you've had no answers, I'll offer my current practice:
I use branches for development, not for keeping different variants going in parallel. The trunk is reserved for my best, presumably working, code on the and I try not to check in anything there that might break it. I branch the code when I want to start a line of development that will take some time, break it for a while, is an experiment I might have to be abandon, etc.
To start a new line of development I change the default branch to a new branch off the trunk rev that's to be the base of my code, and force a checkin onto that branch, with:
rcs -b1.2.1 foo.cpp
ci -f1.2.1 -l foo.cpp
Now I can dive in to developing the branch, and my next check-ins will go onto the new branch instead of onto the trunk. Whether you lock a revision or not is only relevant to whether you intend to modify the working file.
You're correct that you can't keep both revisions, trunk-tip and branch-tip in the same folder; they have the same file name. But you can check out one of them with a -p switch which forces the output to stdout (instead of to a local file) which you can then redirect into a sub-folder, or to a local file with a unique name.
I have local folder that is branch from formal_versions.
My workflow is:
Mkae changes and than commit them
The integrator merge them in his local branch.
The integrator push its local branch to formal_versions
I use pull to make my local branch identical to formal_versions
This is working fine.
However what should I do in the following scenario:
After pull from formal_versions , I compile the code. As a result , some workspace and obj file are changed (I.E date and time of compilation) and of cource , bazaar explorer inform me on modified files
I again want to make my branch mirror of formal version. What should I do?
A. Why using pull again says that "nothing to pull" even if
I use --overwrite switch ? it is suppose to make my local branch as mirror of the pulled branch...
B. Is my only option is to use revert working tree?
It is generally considered best practice (as well as good for one's sanity) not to version files that are the result of the build process. Executables, shared libraries, and even source files generated from by a 4GL are examples. You can ignore files by using bzr ignore <pattern>, for example bzr ignore *.exe. If the files are already versioned, you will also have to remove them using bzr remove.
bzr pull says there is nothing to pull because the formal version has had no new commits since your last pull.
If you must version the files in question, bzr revert is the only way I know of when bzr pull does not find new revisions. If there had been new revisions in the formal branch, the files should be updated (and will potentially be reported as conflicts).