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.
Related
Using free, self-managed GitLab
Due to group-level custom project templates available only to paid tiers (even there there are restrictions) I am looking into an alternative solution using a simple project, where
in the code repository each branch provides a template
in the wiki each code repository branch has an entry documenting what the template does
I know that the wiki and the code are actually two separate repositories.
In its nature a template is a construct that offers a pre-made setup for working on a reoccurring task. A group template adds the additional restriction that the reoccurring task applies to more then one individual.
In order to limit tomfoolery and people pushing whatever they want thinking it's worth becoming a group-level template (even though they made something real quick to tackle a problem that has been long forgotten and even they themselves will not work on it ever again) I would like to impose access restrictions to all members. Beside the maintainer/owner all other members are assigned a developer role. All branches are protected so a change of an existing branch or the creation of a new one can only be done through a merge request leading to an assessment whether the committed changes to the repository are actually worthy of becoming a template for the whole group.
Many members of my group have the bad habit of choosing poor names for functionality they have developed (e.g. a script called jennifers_help_script_23.py) and not documenting what was actually implemented. And yes, we are not a software development company but a research institute. :D So in order to improve the documentation and the ability to actually reuse some of the quite useful things that people have developed I would like to make it mandatory for people to provide documentation if they want their stuff to be added to the project.
So the question here is can a user submit a code merge request that also acts as a merge request for a change in the wiki (e.g. user has created a new template, which requires also a new wiki page documenting that template) or the two have to be handled separately given the nature of a GitLab project (wiki separate from code)?
I was thinking maybe each branch (representing a template) will contain a markdown file that will be inserted as a wiki automatically after the merge request has been approved. However I don't know how to automate this. I am currently looking into uploading a file to the wiki using the GitLab API, hoping a can somehow add a trigger in GitLab to execute the "command" upon a successful merge. Needless to say I am quite new to all of this.
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 use JIRA in our organisation. I am unable to find the branch tag/commit-id against particular feature. Is there something I'm missing?
To understand a feature I want to understand all the changes that were made for this feature. How do I go about finding them?
Assuming your JIRA is connected to some kind of source code management (Bitbucket or Github). The branch / commit name must contain the JIRA issue key.
Jira: assign an existing git branch to an issue
Creating the branch though the UI is just a convenience. The important thing is that the name contains the JIRA key. If only one developer is working on the branch, it's fairly easy to just rename (delete + add) a branch with the appropriate name.
To find all branches / commits related to an issue, there's the Development Panel on the sidebar right.
The jira key in the git commit message we found needs to be in uppsercase, well case senstive depending on what you set in the integration.
In the RTC only owner of the Repository work space can check in the code ?
Other members can only take updates by changing the flow target.
Can I provide access for more than one user in a repository work space (Multiple owners) to deliver the code.
If i create a scoped work space , other members can only view the changes and take updates from it. Is it correct?
In the RTC only owner of the Repository work space can check in the code ?
Yes, the idea is for an owner to not have the surprise, when coming in the morning, to discover his/her own repo workspace with new checkins or having done new deliver without his/her knowledge.
Can I provide access for more than one user in a repository work space (Multiple owners) to deliver the code.
Not to deliver: you need to accept change set from that repo workspace, and publish said change sets from your very own repo workspace (that I recommend to be a scoped one, not a private one)
If i create a scoped work space , other members can only view the changes and take updates from it. Is it correct.
Yes, but the natural flow is to deliver to the stream, or to accept change set from the stream (only one source).
You change that flow target to a colleague repo workspace only if you need it (ie, not every morning, but in the rare occurrence when that colleague has committed some interesting change set but has not deliver them to the stream yet).
The rest of the time, you sync your own (scoped) repo workspace only from the Stream.
My colleague and I are participating in a huge project located in Accurev. We've already created own workspaces backed with some stream (let's call it zzz-stream) which is used by many other participants, not only by us.
The point is that we want to exchange our work between our workspaces, make some changes, exchange again, etc. BEFORE making the changes accessible for others, i.e. in other words we don't want to propagate our changes until it is stable and tested, but we want be able to work on it together.
My idea was to create new stream (yyy-stream) backed with zzz-stream, and then change our workspaces to be backed with yyy-stream. But unfortunately I have no rights to create streams.
My second idea was to use a workspace as backed stream, but it doesn't work because Accurev can't use ws as backed stream.
Is there any solution for our problem?
UPD: I accepted Brad's answer as most detailed. However Accurev is too heavy and sluggish to be used effectively. So actually I prefer to use Git for internal needs over the accurev workspace. (see Accurev externally, git internally)
Your idea of creating the yyy-stream is the EXACT right way to do it. The other options are decent workarounds for one-off situations, but creating the extra stream is simple and is fully leveraging AccuRev's capabilities.
That being said, I understand that your admins have stream creation locked down. They of course want control, but should be allowing for maximizing developer productivity and not forcing workarounds like this. My guess is they have stream creation locked down to a particular group being enforced by the server-admin trigger. One common thing I have seen other large sites do is:
- allow streams to be freely created off of a list of acceptable streams (easy to do in the trigger)
- enforce naming rules on the stream creation. This is important to admins in large sites to keep things organized. Again, this is very easy to enforce via the server-admin trigger.
Bottom line, if this is a common situation, work with the admins to allow this capability as per the above. If they have any questions, they are more than welcome to contact AccuRev and we will help them out.
Your idea on using another stream for you and your peer is a good one and is commonly called a collaboration stream. If your site has stream creation locked down, you would need to work with your AccuRev administrator to make that happen.
Another option is for you and the other developer to pull the keeps from the other workspace into your own stream. This relies on both of you being diligent about doing keeps and then you can look at the history of the other developer's workspace to find the keep operation, right-click that transaction and then select Send to Workspace. The destination workspace must be your own.
A third option (more for a situation where you are in your workspace and know exactly what file you want to grab the other users changes)is to bring up the version browser for the file, right click and select history/browse versions. Look for the other workspace, highlight the version in that workspace, right click and select send to workspace. This will checkout that version into your workspace.
This is similar to the change palette suggestion but quicker if your looking to this on a file basis.
Another idea is to use different version control system (e.g. git or svn) over Accurev workspace to exchange the changes and keep our history separated from zzz-stream. (similar to Accurev externally, git internally) Only changed files should be added to other VCS, not whole project. Some merge problems occur though.