The scope of this is that we have three main projects. Some of the source files are shared between the projects. There are nearly 3 million lines of code (not including comments or spaces) that has grown over 20 years. We currently use Source Safe for our version tracking. But this is starting to fail us as we expand not only our products but also by how many developers we have playing in different modules that are shared. An example of a shared file would be a template class. The code is solid and is used in many projects. It is a single file so it is just shared between the projects. Now 20 years later that one file has grown to over 1000 files (Yes I would love to refactor and make libraries, not happening). Does Mercurial support the same kind of concept in some way?
Thanks
Mark
Mercurial subrepos may be what you're looking for, if I'm reading your question correctly.
Related
I have multiple projects (git-repos). I have opened these in one multi-root workspace using Add Folder to Workspace.... Since these are all Clojure projects, and I have Calva installed, VSCode identified the correct LSP server clojure-lsp. But VS Code starts one LSP server for each folder/project in my multi-root workspace. I want only one.
How can I tell VS Code to start only one LSP server for all folders in my workspace?
At the time of this writing, this is not supported. See multi root support? #280. If you look at their projects page, that issue ticket is currently placed in the "Low priority" lane.
You can show your support for the feature reuqest by giving a thumbs up reaction to the issue. But please don't make a "me too" comment. "me too" comments generally come off as annoying to repo maintainers because they clutter up discussion and don't contribute anything of significant value.
Some quotes from the discussion there:
lucywang000:
I noticed that python's pyright lsp only fires up one instance for multiple python projects, would it make sense to have a similar feature in clojure-lsp?
Some related quote from the doc (https://github.com/microsoft/pyright/blob/master/docs/configuration.md):
Multi-root workspaces (“Add Folder to Workspace…”) are supported, and each workspace root can have its own “pyrightconfig.json” file.
I used to open lots (5-10) of clojure/script projects, for e.g reading 3rdparty libs code. It doesn't make sense to have 10 lsp instances running and take up to 10-20GB of memory ...
ericdallo:
Yeah, it sound a good idea, but I'm not sure this works for most of clients, including lsp-mode (lsp-clojure.el), it'd need some extra work on their side, and I'm no sure what need to be done on server side too
bpringe:
I was thinking about this recently. I think this is a good idea, though I know it might take some time and thought to implement well.
bpringe:
Another thing to consider is that if the memory usage of clojure-lsp can be drastically reduced via graalvm and other methods, this becomes less of a problem. I still think it's a worthwhile thing to do in any case, though.
Edit: Linking #229
snoe
I know some workplaces do multi repo/multi project/multi language stuff but it should be understood there's costs there, particularly around tooling support and it should be clear that those places should be investing in their tools.
I think that comparing ourselves to things like intellij or vscode backed by huge companies and hundreds of devs is a losing proposition.
So, in the end, my view is that collaboration and PRs can be welcome, but understand there's a high effort to maintain compatibility and performance and stability across servers and clients and to do the testing across those environments.
Our sw project uses for its build process different libs (popular as well as special ones) and a framework. The libs never change, whereas the framework could be changed from time to time to an updated version.
For extended further developing we want to use a version control system. Which of these solutions is the most elegant one:
The full project with all libs and the framework gets uploaded in the version control system's repository thus everyone has exactly the same files, but the use of space in the repository is enormous.
Only the artifacts of the project which are getting effectively changed over time (the main program) are in the repository. Used libs and the framework are stored on a central NAS. -> Files could be used for other projects, too.
Like 2, but everyone hast a copy of the libs and the framework on his local workspace.
For my taste solution 2 or 3 sound better, because I think that the repository should be as light as possible. What are you recommending?
This is obviously a matter of opinion, but my opinion is that the most important characteristic of version control is the ability to reproduce source at a particular point. That includes libraries. There are downsides (boost is huge, for example), but it guarantees that everyone gets the same code, especially in the case of obsolete or unsupported libraries.
You can have both; structure your source control so that it separates your source and your lib/framework. People can put them in different places locally if they so choose, but everybody will have the same codebases.
Disks are cheap; time wasted trying to figure out why people aren't all seeing the same thing isn't. The most important thing is that everyone stay in synch.
Are there any performance (in load time or usability) drawbacks when having lots of projects in one Eclipse workspace?
What difference makes when I close project I'm not working on?
Do working sets have any benefits to performance. I know it helps a lot in organizing projects, but what when I'll have lots of working sets, each with lots of projects?
Having lots of open projects will slow down startup, refresh, and all the background tasks that rummage through source files looking for problems. Usability depends on whether you need all those projects open - whether it gets hard to find what you're after - nothing to provide a solid answer about.
Closing projects brings them down to virtually no cost at all.
Working sets don't benefit performance directly. They obviously will help when you reduce the scope of operations, like searching, by using them.
Closing projects you're not working on, also has the usability benefit of a better overview in the package Explorer.
Closed projects are automatically collapsed by Eclipse and the Icon (blue closed Folder) also has less Subicons like warnings, the little Maven "M" etc. That makes it less distracting by scanning over your projects and looking for the relevant ones.
To close projects you're not currently working on is definitely a good idea.
(Mainly because of the issues Ed mentioned in his answer)
If you definitely won't be needing the project anymore, you may as well remove it from your workspace. Gives you an even better overview ;-)
My client is migrating from Source Safe to Clearcase. They need to list all the link files in the Source Safe database so the links can be carried over to Clearcase, as apparently all the source must be checked into Clearcase on day 1, losing any existing links.
Are there any tools for creating this report, or perhaps even doing the full import into clearcase ?
My plan is to write a powershell script to recurse Source Safe the SS folders, findings links using COM.
Thanks.
As I have mentioned in this question, clearexport_ssafe should be used for import from Source Safe to ClearCase.
However, the documentation for that tool explicitly mentions:
Shares. There is no feature in Rational ClearCase equivalent to a Visual SourceSafe share. clearexport_ssafe does not preserve shares as hard links during conversion. Instead, shares become separate elements
So your script would need to list all links, and create soft links between their initial directory and the newly created separate element.
But I believe you may want to consider another organization for the target ClearCase repository, one in which all share files are no longer directly used, as illustrated by this answer (for SVN repository in this instance):
We have eliminated all of our linked files. All class files that were previously linked have been placed into class libraries which are shared to our other projects as shared project references in the solution. So in essence you share libraries, not class files.
There was a bit of an adjustment process getting used to this, but I haven't missed links since then. It really does promote a better design practice by having your code setup like this.
I work mainly with UCM, and all those "share" are natural candidate for UCM component, with UCM baselines to refer to their different version, and you can then make your own "configuration" (list of labels) in order to select the different components you need, making them easily reusable across projects.
As VonC mentioned, the import from VSS to ClearCase is truly atrocious as:
The export/import takes forever to complete, so much so we open a PMR against IBM for it (that didn't help, btw)
The Source Safe shares are transformed into files, which is creating duplicates all over the place (the horror !).
I work on ClearCase UCM myself, and we took the same decision as you (which, in my 10 years of experience in CM, is ALWAYS the best decision): leave the history behind for reference and import at most a couple of versions one on top of the others, by hand (like current in development ; current in test ; current in live).
The way we solved the shares' problem is as follow:
The "shares" where isolated from the source-tree, to be imported independantly from the other sources
The other sources where imported (without the history and without the shares) from scratch. Let say in a component called MAIN_SRC
The shares where imported (without the history) from scratch. Let say in a component called SHARE_SRC
A project was created containing both components: MAIN___SRC, and SHARE_SRC.
Now, the problem is not solved because your shares are living aside your main source code, when your IDE (e.g. Visual Studio) fully expects them to be in the same folders they were before (i.e. in Visual all your projects become wrong if you don't solve this issue, and all the files would need to be relinked from within Visual itself, etc... A lot of work).
This is resolved by using ClearCase VOB symbolic links:
Let says in MAIN___SRC you need to use a file called myShared file in SHARE_SRC.
From within the folder needing to use the myShared file, use the command line interface and run:
cleartool ln -s ..\..\SHARE_SRC\(myPath)\mySharedFile .
You need as many ..\.. as necessary to go up to the component folder level in ClearCase, and then down following your path (myPath) in the SHARE_SRC component folder.
Remember the ClearCase path is composed of:
M:\View_name\VOB_name\Component_name\Your first level of files and folders
( VOB_name\Component_name is the "root" of the component, apart if you have single component VOB, in this case VOB_name\Component_name becomes just VOB_name)
The easiest way is to have a mapping of all the VOB symbolic links that need to be created, and put all necessary "cleartool ln -s" command lines in a script to run once.
After that, you should be fine, and your IDE think the sources are where they used to be.
Cheers,
Thomas
I do alot of bugfixing and implementing new features for several different customers. These customers all report their bugs, change requests and new feature request into our Trac system.
Sometimes these requests result in me creating some SQL change scripts, sometimes there are Excel documents or Access databases with testdata, Word documents from the customer and so on. Alot of files that are used to fix one ticket and then can be deletede when the ticket is closed.
I usualy do this by creating folders in the filesystem like this: /customerXX/TicketNNNNN and then just dumping everything in there.
How do you organize your workfiles? Have you found some fantastic tool to do this?
I would say for scripts or files that are related to a particular ticket, the best thing to do would be to attach the file to that ticket in your issue tracking software - almost all issue trackers that I've worked with will allow you to do this. That way, you can look back and a) see exactly what you did in case something goes wrong, or b) do exactly the same thing if the issue comes up again later. That's almost certainly the best place to keep files with extra info from the customer, too (or at least the first place most people will look).
For frequently re-used scripts that aren't specific to a particular ticket, I would create a scripts/ or bin/ directory in the associated project, and keep them in there.
I also have a small handful of useful files that I keep in src/misc/ off my home directory, with things like SQL queries to get readable "explain" output out of Oracle and such, that aren't specific to any particular project. The number of these is small enough that subdirectories aren't necessary, though - I suspect if you ended up with a large number of these files, many of them could/should be moved to specific projects or your issue tracking system.
JIRA has been quite helpful for this at my site. It supports issue tracking, file attachments,and you can easily customize and categorize your projects and issues.
I use Fogbugz and I add all file to the case. I believe that no matter what application you use, The important is to keep this files for future references. If your bug-tracking tool does not let you attach file then add the files to the version control.
We use CaWeb4 and find it very easy to use for our bug tracking.