externals

I've read a few answers on here that condemn the use of svn:externals. I do see how they can be misused, and it does make us more dependent on Subversion, but I really don't see our group moving away from it anytime soon. Anyway, here's my dilemma. We have Solutions that reference multiple Projects which are in their own section of the repository. Many of these Projects are shared between multiple Solutions, and we also don't want to preclude the sharing of our Projects. We also have several fixed version dependencies checked into our repository (unit test frameworks, libraries, etc.). I would

I've made one svn:external in my repository. Everything works fine, except the output of the svn status command. In the output there is lot of information I don't need: $ svn st X lib Performing status on external item at 'lib' I can run svn st --ignore-externals -q and I can place this line in a small script, but maybe there is better solution. How can I see status of my working copy without seeing info about externals? That seems to be the proper way to ignore externals to appear in your svn status output. Reference: http://svnbook.red-bean.com/en/1.4/svn.ref.svn.html Searching turns up a

I would not get to know svn:externals if I haven't run into the this page . So, I setup my working folder. Then mkdir lib/vendor svn add --parents lib/vendor svn ps svn:externals 'symfony http://svn.symfony-project.com/branches/1.4/' lib/vendor/ svn ci -m "add externals" svn update The "svn update" enlists the whole symfony folder and is pretty slow. I thought that would be single time pain. However, SVN will check external repository every time I typed "svn up". I have to use --ignore-externals to make "svn update" fast enough. I'm wondering what's the benefits of svn:externals if it is so

I'm looking into svn externals for my company, and it seems like it would be a good feature for us to use. We have several products that often reference shared components, but have a bad habit of falling behind into older versions and even differently branched codebases sometimes. I've read a decent bit about how they work now, and I think I understand the concept OK. What I'm not 100% sure on is how different revisions of multiple repositories link together. Let's say I have a Product and a Library. The Product is built against the Library, so its repo has a svn:externals property that links

I have a web application that is written with React and bundled with Webpack. The application has a JSON config file that I want to include at runtime and not to be bundled with webpack. In my entry point for the application I am importing the contents using the json-loader but doing that forces the file to be embedded in the application and I can't update the config file once it's been bundled. How can I configure my webpack.config.js file to exclude my config.json file but still let me import it in my application? It's not a module so I don't know if it can be included in the externals

We are considering a move from SVN to Mercurial, and have encountered a stumbling block. We currently use svn:externals to automatically pull a common set of libraries into the working directory. I can't find support for anything like this in Mercurial. Is there a way to do this automatically with Mercurial, or do I need to fake it as part of my build process? Ry4an Brase There's no good way to do it using mercurial only. The Forest Extension mentioned elsewhere causes more problems that in fixes nowadays. Most folks just use a large repo and include all their components in the repo and then

We've got in a corporate environment an svn repository structure which looks like this: root libs shared_lib1 shared_lib2 private_lib public_code private_code where public_code is an external repository which is open source and where people from outside the company have read-write-access. shared_lib1 and shared_lib2 are also external repositories shared with a different group of programmers from an other company. I'm the maintainer and can do basically whatever is technically best, the outside users will have to adapt. I'm now wondering what the best way is to move from this structure to a