I have project A, which includes a local fork of project B.
This is, project B's potentially modified sources are included in a subtree of project A.
Project A uses svn, project B uses git.
Using git for my local copy of project A, I want to:
Be able to merge project B's upstream changes into project A.
Be able to contribute back to project B some (not all) of the modifications to project B's fork included in project A.
Do it in such a way that clean individual commits (not squashed) are sent both to project A (via git-svn) and to project B (via git).
I've been trying hard to find a solution mixing git-svn and git-subtree capabilities (git-submodule is out of question as I want a unique source tree). But I can't find a perfect solution.
Related
I have two independent .net projects. One is like a project which is baiscalliy to process invoice and another project is something which I am calling as common as I am keeping all sharable/reusable code under that.
Now any project can consume this common-project by adding it via add Existing project option so that source code will not move to consumer project which is Invoice management in my case.
Now if I add common project as reference and run my CI pipeline its failed as its not able to find the path of common project which is obvious as it may be different from my local machine to build server.
Now the solution that I am aware of are below :
Make common as Nuget package and use it under invoice management.
Build common project dll at some centralized file server and give that path in Invoice management
for reference instead of absolute path.
Both solutions are not simple to implement so I am looking for any better quick solution for the situation where project setup is like this and CI build has to execute.
The best would be actually reference via NuGet package. However, there is a third option which I do not recommend. You can use multiple repository pipeline. You will checkout there two repositories. In thi case you have to mimic folder structure wich you will get on AzureDevops. Otherwise build will fail as it will not find the references.
I have the following (simplified) solution structure:
ProjectA
|- Content: myexe.exe with CopyIfNewer
ProjectB
|- ProjRef: ProjectA
ProjectC
|- ProjRef: ProjectB
When I run a build of ProjectC where ProjectA is built also (e.g., because ProjectA is not up-to-date, or because I clicked "Rebuild all") then myexe.exe is put into ProjectC's bin output folder. However, in any other case, myexe.exe is NOT in ProjectC's bin output folder.
Is this a known problem? Am I doing something wrong? How to fix this?
However, in any other case, myexe.exe is NOT in ProjectC's bin output
folder.
Is this a known problem? Am I doing something wrong? How to fix this?
Test
First, l guess that the first project is a ,net framework project or even the three projects are based on the framework. In my side, l created such three projects and cited the relationships you mentioned for the three projects.Exactly, when I modified the codes of Project C(A and B already built before), the file cannot copy into Project C as you wish. But when l just have two projects A,B(B project reference:A), it always copy the files of the first project A into B(whenever l choose Copy always or Copy if newer or build or rebuild the project B). Besides,I tested three projects which are based on Net Core or .Net Standard works without problems.
Conclusion
So the reason for this problem is pointed out that the intermediate project, project B, is not built（up-to-date Skips the build ), so the files of Project A could not be copied to the Project C as the transit station. (especially for non-sdk framework projects). l think it is a feature or issue in Project Reference in Visual Studio. or you could report it to DC Forum for a detailed explanation.
Solution
You can add such property to the csproj file of project B to break the latest check and ensure that it is always built. You can add this node under PropertyGroup both in Debug or Release
<DisableFastUpToDateCheck> true </DisableFastUpToDateCheck>
Hope it could help you.
Is there a command-line tool to automate maintaining a collection of source libraries and applying them to projects?
For gamejams (or possibly also longer-term projects), I don't want to host my own clone of each library I use to be able to modify it (and grant each member of my team permission on each clone). Instead, I want all of my source code inside my project source tree -- which means I can't use git submodules.
So say I have a project "puppypark" and I want to use some libraries "baton" and "windfield".
I'm looking for this kind of workflow:
register libraries
librarian add baton git://lib.com/baton.git
clones to a central repository (e.g., in ~/.librarian/)
add libraries to a project
librarian use baton puppypark ./src/foreign/
creates a branch (off master) for that project in the central repository
merge project changes into central repository
librarian apply puppypark
switches to project's branch and copies changes into clone
merge upstream changes into project
librarian apply baton puppypark
takes the current state of project's branch and copies to project
no actions occur unless the target repository has a clean workspace
actions always result in commit summarizing the action taken
commits should always have a commit id (sha)
This could be independent of my version control system, but if it did it with git, that's great too.
I think this is kinda like Carthage (but for source instead of built libraries and I'm not interested in dependencies). Maybe I can achieve some of this with git-subtree, but I don't understand how. I think this is like loverboy, but I'm interested in a more general solution.
I couldn't find a solution, so I wrote my own: librarian automates copying modules to and from projects. Unlike loverboy, you give it general rules for how to copy modules instead of requiring rules for each module.
Example usage to setup for love2d and import windfield into project "puppypark":
librarian config love --path src/lib/ --root-marker init.lua --rename-single-file-root-marker ".*.lua" --include-pattern ".*.lua|LICENSE.*"
librarian acquire love windfield https://github.com/adnzzzzZ/windfield.git
librarian checkout puppypark windfield
librarian checkin puppypark windfield
Context:
We're creating a new solution consisting of multiple app portals (for lack of a better term), each portal will need to leverage off of a base project that will already include some of my employed proprietary code, as well as any new features pertaining to that portal. Our current app leaves much to be desired, and as we're getting a fresh start, we'd like to go at it the right way. (Thus I'd like to rubberduck my thoughts somewhat)
I've thought of a few possible ways to solve this. Each with it's pro' and cons.
1. GIT Fork A Base Project:
This seems like the most straight forward way. Have a PortalCore
project, then have each project fork it in a downstream only fashion.
Con: If the base changes, we'll need to manually update all of the dependant projects.
Pro: Easier to implement initially, and I believe will reduce some of the other more "laborious" tasks. (Example, single build file that will travel with each new portal with our build requirements.)
The flow would be:
Fork PortalCore > Core will be kept up to date via updating via GIT master
2. Base Project NPM Package:
This seems like an ideal route, as with each deployment the latest version of our base package/project will be installed with each portal.
Con: From my research it seems like we're not able to have a npm package install outside of the npm folder (this pertains to my question). We'll need to share the build file via some other means if we want it to sit in the project root.
Pro: Updates automatically rolled out with the build process
The flow would be:
New Project > Add Portal Core npm > Make custom build task, or grab
from some central repo > Will be kept up to date via npm install >
Gulp Build
3. Combination of the above
Have a git project only containing our base npm modules, & build config. The build can then handle things like moving files to the right location (example. node_modles -> root)
The flow would be:
Fork PortalCore > Core will be kept up to date via npm install > Gulp Build
Questions:
Is there a way to have an npm package (or another package manager) install files to a specific location? (I have checked the npm forum, and this seems like a dead end. But I thought I'd try my luck here)
Are we frankensteining it? We don't want to create a new monster. Does this logic make sense ITO creating something that should be somewhat modular by design, but allows for easier maintenance. How do the big boys do this... if they do this?
The answer to this ended up being much simpler than I expected:
Put all shared services in separate common NPM packages (common components,shared / common services, etc.)
And create a few yeoman generators that assists with initial project
initialisation. (The only drawback is someone needs to maintain them,
should some new core dependency come along... but such is dev life.)
I have two maven projects A and B, both of which I'm actively working on the source code for. Project A depends on B. If I want to build project A, does a snapshot (or release) of B need to exist in the repository? Or will maven check the parent directory of A to see if a project B exists (assuming my directory structure looks something like: projects/A projects/B)? And which would be better practice? thanks.
Jeff
Maven won't look anywhere except the repository hierarchy you specify, by default this is your .m2 directory (local repository) and the Maven Central Repository.
So yes, some version of B must exist in a repository.
You can also investigate project modules, where you have (for example) projects/pom.xml and when it is built, it will also build its children A and B in the correct order given their inter-dependencies - but you shouldn't see this as a solution to the problem you're describing without giving a lot of thought.
To get a good grasp on how the Dependency Mechanism works in maven and how to configure parent-child/submodule/subproject relations read this
Maven is a strange build tool in that it will look to the maven repository / artifactory for jars. As long as someone has built ProjectB and installed it in the artifactory, or as long as you have built ProjectB (with install) it will be available to ProjectA.
This also assumes you have setup the dependancy correctly in the pom file for ProjectA.
I used Maven on one project, and I'll go back to ant for a more standard build tool. It's really an odd duck.