I have multiple projects with common in-house JavaScript library dependencies. I want to share these dependencies across multiple projects.
Unfortunately we are using TFS. I'd like something like svn:externals, whereby I can link a particular folder to a different folder elsewhere in the source control tree. So I want to have
ProjectA
app
js
lib [should link to SharedProject/lib]
ProjectB
app
js
lib [should link to SharedProject/lib]
SharedProject
lib
library1.js
library2.js
I don't want to link across workspaces...I don't want a crazy custom per-developer setup. I just want developers to check out one project, and it knows "Oh, there are shared resources in this other project. I'll get those too." I don't care about it always getting a specific version; I'm just tired of copying files across projects.
Is this remotely possible in TFS? I have Googled and found nothing conclusive.
Just branch the shared project from its original location to where you want it to be.
When you would switch to next revision on svn:externals, simply merge changes up to that revision to the branched copy.
(frankly I prefer this way even on SVN)
Using external link in source is not a good idea. It creates lot of side effects. You can package and publish your library using NuGet to a private NuGet server and then consume the published packages in all the dependent projects.
Related
I want to build my portfolio on GitHub. I have a few Java projects and I used Eclipse to build them. How should I share them on GitHub?
Should I share only the src folder? That way, however, I would end up losing some dependencies (databases or img folder etc.).
Is it good practice to share the Eclipse workspace on GitHub? If I use third party libraries these will be included too though.
Sharing only the bin folder would be mostly pointless. Basically, if you want to share your projects in Github, the expectation is that you are also sharing your source code as well. Sharing only the src folder would still be mainly pointless, both for the missing resources you already mentioned and also for missing project metadata (e.g. required Java version, project name, etc.) that gets stored there. Without this metadata it might be still possible to compile your projects, but having the project metadata included allows others to simply check it out into an Eclipse instance, and it should compile and run without any extra configuration required.
Sharing a workspace is a bad idea, as your workspace .metadata folder contains your preference settings, file system references (sometimes referring to absolute paths on your computer), and sometimes even passwords. I would not recommend doing it.
To be more constructive, I would suggest to do the following:
Categorize your projects, and create a separate repository for each different project. This helps to show you are building several things that can be used separately. Of course, if some projects belong together, share them inside a common repository.
When you create a repository, generate a gitignore file related your project type (e.g. Java project) - see screenshot below. This sets up the repository in a way that you are not uploading class files, etc. that is unnecessary in a source code repository.
Share your projects one-by-one into this repository. Eclipse has the EGit project that supports this aspect (most likely it is already installed if you have a not too old Eclipse instance.
I have the following directory structure:
CommonUtilities, DataStructure1 and DataStructure2 contain source files used by one or more projects.
I would like to publish one or more projects as open source using Mercurial and BitBucket. But I don't know how to manage the source files used by one or more projects.
I am new to source control and to software development in general, so I would like to know the best practices in this kind of situation.
Should I:
Include the common source files in more repositories as needed?
(that is hg add them to two or more repositories)
Include the common files in some other way than hg add?
Do something completely different?
Option 3: Do something completely different.
You can use the subrepository feature: keep the common files in a different repo, then reference them from your repository.
You are trying to solve the issue by wrong tool. The best way to manage such situation is a dependency management tool (look at Maven, Ivy or Gradle).
So I would like to use NuGet to manage the various projects I use for a specific project my team and I are working on. Up to this point, I have placed my .js library files in the /Scripts directory of my web solution (ASP.NET MVC 2) and referenced those. Of course, this was manual and was annoying to manage during upgrades, etc.
Now that I am using NuGet, I realize that the entire goal of NuGet is to make this fairly painless. In addition, it appears that I shouldn't have to check my packages into my repository (AKA I don't need to manage my external libraries anymore). However, when I grab jQuery (for example) from NuGet, it places its specific files in the /Scripts directory of my project.
Where I get confused - what, if anything, should I check into source control at this point? Do I still check in the /Scripts directory?
In addition, if someone else is working on this project and checks out the solution from source control, are the packages automatically downloaded (assuming the solution comes with a valid packages.config)?
I'm just trying to clarify a couple points before we start using NuGet full-time.
There are two scenarios for NuGet vs VCS: to check-in or not to check-in, that's the question.
Both are valid in my opinion, but when using TFS as VCS, I'd definitely go for a no-checkin policy for NuGet packages.
That being said, even when using a no-checkin policy for NuGet packages, I'd still checkin the content changes that those NuGet packages have done to my projects. The \Scripts folder would be checked-in in its entirety (not selective, not ignored).
The no-checkin policy for packages to me means: not checking in the \Packages folder (cloak it, ignore it), except for the \Packages\repositories.config file.
As such, you are effectively not committing any NuGet packages, and when using Enable-PackageRestore from the NuGetPowerTools (this will be built-in in NuGet v1.6 just around the corner), any machine that checks out the code and builds, will fetch all required NuGet dependencies in a pre-build step.
This is true for both local development machines as for build servers, as long as Enable-PackageRestore is enabled in your solution and points to the correct NuGet repositories (local, internal, external).
If you think about it, when installing a NuGet package that only adds references to some binaries, you'd already be doing the samething in a no-checkin scenario: you would not commit the \Packages folder's subfolders, but still, you'd commit the project changes (the added reference).
I'd say, be consistent (for any type of package), whether it contains binaries only, content only, or a mix. Do not commit the packages themselves, do commit the changes to your sources. (if only to avoid the hassle of looking up what changed content-wise)
NuGet, like Nexus, are artifact repository (artifact being any type of deliverable, including potentially large binary).
The side-effect is for you to not store in an VCS (Version Control System) elements that:
wouldn't benefit from VCS features (branching, merging)
would increase significantly the size of the VCS repository (no delta or weak delta storage)
would be quite hard to remove from a VCS repository (designed primarily to keep the history)
But the goal is for you to declare what you need (and let NuGet fetch it for you) instead of storing it yourself.
So you can version /Scripts as a placeholder, but you don't need anymore to versioned any of its content now fetched automatically.
I have one Eclipse Workspace containing two projects.
- The first is my actual library.
- The second is example code for using the library.
When I push this code to GitHub, I don't want two separate projects, I want the example code to go into an "example" folder of the second library.
How and where would I do this? From Eclipse, GIT, or GitHub?
Or is there a better way of including sample code in GitHub projects? (the example code doesn't actually need any version control)
What if I decide to add more than one sample project?
You can apply source-control to projects in one wokspace, project by project is that pointng to different nodes
Please see Tutorials Git with Eclipse (EGit) and Git, Github and Egit Eclipse integration
Hopes that helps
After more experience with Git and GitHub over my belt, now days I usually place any example code in a separate orphaned branch.
This has several benefits over placing examples into a sub-folder. Primarily, any changes or additions to the examples (Which obviously aren't critical to the library) won't give unnecessary notices of the library code being "changed", or even "ahead" of code in any forks. Also, this setup works well with Eclipse, since both projects will then have their own separate local repositories.
It's also a good idea (and I often forget) to point out this "example" branch in the README.
I am looking at putting a code base that runs several website into version control. There are several instance of this code base running websites on different virtual servers.
The problem I'm grappling with is that each of these separate instances of more or less the same code have sub-directories with site-specific functions. But it seems that version control systems want to control the entire directory hierarchy.
For instance, each instance has the directory
/www/smarty/libs/plugins/
Where you'll find site-specific functions for smarty. When we are ready to put it into version control, the folder /www would be the root.
So one option is to have all the site-specific functions going out to all sites. I don't see a problem in and of itself, but it seems somehow architecturally 'wrong'. There would be a bunch of files that only belong to one deployment.
Another option is to have a separate repository for each site's specific files within the code base. But that sounds like it could quickly become a nightmare when trying to get new sites deployed properly.
What's the best way to do this? The version control system we're looking at is subversion.
Generally, source control systems should be used to control source. They are not at their best completely controlling file hierarchies, permissions, and other related things. These are best left to deployment configuration.
How about having each of the projects and directories you need represented once in the version control system. Then, in a separate directory (perhaps called /build/), have the various configuration layouts. You might have an ant file that builds each site, or maven. Or you can use tools like Capistrano or Fabric to have more control over each deployment.
The tools are made to be flexible (generally), so here are some suggestions:
Most VCS' allow you to ignore files and directories through some mechanism (e.g. Mercurial .hg ignore file), so you should be able to target what you want/should control versus what shouldn't be.
Separate the files/directories into common resource project and site-specific projects and then use a build system to integrate them to create a deployable package. The build system can be as simple as a shell script or a more sophisticated framework. If its a really simple integration, the VCS may have some basic features for merging bases (e.g. Mercurial subrespositories).
With subversion, you could have a bunch of repositories:
www be in a general repository
plugins each be in a site-specific repository
Then have nested working copies:
svn co http://www_repo www
cd www/smarty/libs
svn co http://foo_plugins_repo plugins
Tip: add plugins to svn:ignore property of www/smarty/libs
svn propset svn:ignore "plugins" www/smarty/libs
You could certainly do that with git too (through .gitignore), and probably with other version control systems but I don't know them.
(Alternatively you could skip the nested working copy part (which can freak some people out) and check out stuff side by side, but use a symlink in lieu of smarty/libs/plugins, while ignore still pertains)
You're missing a "build" step, which whould take the source in source control and create the deployment bundles for the different sites. Only one source package is needed, different build configurations create the different deployment packages. Don't try to directly put the deplyoment set into source control, it is not the source!
I believe the best thing to do would be to create a top level directory in your repository for each site (Site-01, Site-02, etc) and inside those directories put the source tree. Then you can checkout the projects separately. I think it's acceptable and somewhat standard to use the same repository for all the projects your company is involved with.
My terminology might be off kilter, but the fundamental idea is sound, I believe.