My team and I are in the process of changing our development flows using NaturalOne to more conventional methods in order to better take advantage of our Git CMS and associated tools, but have run into a small but significant issue with running in Private mode. Most of the troubles come from the fact that each developer may work on between 3 to 5 relatively small, unrelated projects concurrently.
Here’s the situation. We have a team of 7 developers working on a large, +15,000 object system, all of which is kept in a single APROD library in a NaturalOne project. What we’ve been doing so far is when we want to work on a program or a series of programs, we create a new custom library and save copies of the programs in question into the new library. Before merging back into the master branch we overwrite the APROD versions of the programs with the version we had previously saved out and then delete our working versions.
We want to instead move to working directly out of the APROD library and use private mode with private libraries to avoid stepping on each other toes. The trouble comes that when a developer wants to switch projects they’re working on, we’d want to be able to change the Private Library we’re working in without deleting the code we previously had been working on (and may have setup for user testing). The trouble is that when we go into the library properties and click on the “Delete Private-mode Library” in order to set a new private library, it deletes the code and old library from Natural Server.
If there is a setting or customization we can make that would allow us to change the library without deleting the server side code, it’d be appreciated. If you have any questions or need a clarification on anything I’ve mentioned here, please ask.
Thanks,
Lawrence
Intermediate Software Developer
Ducks Unlimited Canada
We’re still finding our own way in the NaturalONE world but, as nobody else has stepped up to the plate, I’ll try and help.
You don’t really share a private mode library on the server - each user has their own. If someone else is working on the same project, they create their own private mode library when they do a build. The same is true with one user having multiple projects with the same base library set to private mode. Each project has a separate private mode library.
The way I’d try working would be to create a new project for each unit of work and reference the main project in the new project’s preferences. Make all your changes in private mode then, when you’re ready, copy the new/changed objects back into the main project.
If you keep the new projects in GIT another developer could check it out and, after a build, would have their own private mode library for that project. That way each of the developer’s projects are kept separate but are also shareable should the work need to be reassigned.
As I said, I’m no expert so caveat emptor. There’s probably ways of working with versioning system branches and baselines that will do the job too. Over to the GIT experts.
Thanks for taking the time and taking a swing at this.
Actually, what you describe is pretty close to an earlier iteration of how we were working in SVN, which worked fine for us for a long time. But then we started using some Atlassian tools and found that we were leaving a lot of that functionality on the table or would have to do unwieldy back flips to make it work. We’d really like to get branches inside a standing project working if we can. In fact I think it’s more likely we’ll have to deal with everyone have one library for everything they do rather than going back to that.
Thanks, anyway. It was a good thought and it is a solution but just not the direction we were hoping to go.
I’m not sure if the question is still relevant for you, but in case it is, I see the following option. If I understand you right, you are working with feature branches and would like to keep a private library on the server per user and feature branch.
Instead of having the users switch branches in the same Eclipse workspace when switching between features, you could have them working on a different workspace per feature branch.
As an example: Assume user Bob is working on feature branch A, B and C in parallel, he could have dedicated workspaces A, B and C for the work on these features. In workspace A he maps to the NDV as user BOBA, in workspace B as user BOBB, in workspace C as user BOBC. On the development server we would then see the private libraries BOBA, BOBB and BOBC in parallel. Would this be an option?
There’s probably ways of working with versioning system branches and baselines that will do the job too. Over to the GIT experts. 