In scm Manager I would like to change the name of a namespace that contains svn code repositories.
The namespaces in SCM-Manager are handled by the "Namespace Strategy" which can be set in the global settings. This strategy is used, when a new repository is created. To set your own namespaces, you can set this to "Custom". To change the name and the namespace of a repository, just open the repository settings and select "Rename Repository" in the lower part (the namespace can only be changed, if the namespace strategy is set to "Custom").
It is not possible to "rename" a namespace as a whole, so this must be done for each repository individually.
Related
let's say I have two separate cmake projects, namely:
.../mylib1/ (CMakelists.txt)
project(mylib_1)
add_library(mylib STATIC ${SOURCES})
...
.../mylib2/ (CMakelists.txt)
project(mylib_2)
add_library(mylib STATIC ${SOURCES})
Now if my app project had:
.../app/: (CMakelists.txt)
add_subdirectories(mylib1)
add_subdirectories(mylib2)
cmake would complain about there being two library targets with the same name. To get around this problem, I use the export functionality:
export(EXPORT <export-name> [NAMESPACE <namespace>] [FILE <filename>])
so I have something like:
project(mylib_1)
add_library(mylib STATIC ${SOURCES})
install(TARGETS mylib Export myExports ...)
export(myExports NAMESPACE One)
And the root project accessing these projects would:
execute_process(COMMAND cmake path/to/lib1
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/lib1
)
include(${CMAKE_BINARY_DIR}/lib1/myExports.cmake)
after that, one would use for example:
target_link_libraries(app mylib One::mylib)
target_link_libraries(app mylib Two::mylib)
so there is no name clash. This works fine but this requires me modifying the packages that I am trying to include. So I was wondering if there is anyway of processing these export files and assign/change their namespaces at the parent level.
The reason I am interested in this setup is if for example, I wanted to use two versions of the same library or if I had project A depending on project B and C who both depend on project D. I could leave the name space in D to be something that will be evaluated dynamically based on its hierarchy in the project: ie A-B or A-C But I don't think that's a nice way of doing that.
So is there any way of importing/processing an export file and give it a new namespace?
I'm trying to implement a mercurial pre-push hook which checks the target repo path and adds the appropriate id by ssh-add. The not so nice solution would be checking the command line parameters and if the path isn't forced, then reading the default from the hgrc file but is there a cleaner way to just obtain the remote path?
I printed the kwargs passed into the hook method but there isn't any which seem to hold what I need. I also tried googling but the info available is next to nothing and this appears to be a bit like a black art really. So, any reference to a decent documentation and/or examples would be appreciated too.
Cheers,
Looking in hg help config, it seems like you can use the 'prechangegroup' hook and the HG_URL environment variable:
"prechangegroup"
Run before a changegroup is added via push, pull or unbundle. Exit
status 0 allows the changegroup to proceed. Non-zero status will cause
the push, pull or unbundle to fail. URL from which changes will come is
in "$HG_URL".
You should be able to use the 'pre-changegroup' and 'pre-push' hook (mind the dash). Which supplies the command line arguments as $HG_ARGS.
If the $HG_ARGS is a valid url you can use that url. If nothing is supplied use the ui object that is given as a keyword argument to the hook.
Use the following to retreive the default path from the configuration: ui.config('paths', 'default')
As you can also write other named urls/paths in the configuration file you should also be able to verify the $HG_ARGS if it doesn't contain a valid url a a keyword to the ui.config paths object
I want to reexecute some targets when the configuration changes.
Consider this example:
I have a configuration variable (that is either read from environment variables or a config.local file):
CONF:=...
Based on this variable CONF, I assemble a header file conf.hpp like this:
conf.hpp:
buildConfHeader $(CONF)
Now, of course, I want to rebuild this header if the configuration variable changes, because otherwise the header would not reflect the new configuration. But how can I track this with make? The configuration variable is not tied to a file, as it may be read from environment variables.
Is there any way to achieve this?
I have figured it out. Hopefully this will help anyone having the same problem:
I build a file name from the configuration itself, so if we have
CONF:=a b c d e
then I create a configuration identifier by replacing the spaces with underscores, i.e.,
null:=
space:= $(null) #
CONFID:= $(subst $(space),_,$(strip $(CONF))).conf
which will result in CONFID=a_b_c_d_e.conf
Now, I use this $(CONFID) as dependency for the conf.hpp target. In addition, I add a rule for $(CONFID) to delete old .conf files and create a new one:
$(CONFID):
rm -f *.conf #remove old .conf files, -f so no error when no .conf files are found
touch $(CONFID) #create a new file with the right name
conf.hpp: $(CONFID)
buildConfHeader $(CONF)
Now everything works fine. The file with name $(CONFID) tracks the configuration used to build the current conf.hpp. If the configuration changes, then $(CONFID) will point to a non-existant .conf file. Thus, the first rule will be executed, the old conf will be deleted and a new one will be created. The header will be updated. Exactly what I want :)
There is no way for make to know what to rebuild if the configuration changed via a macro or environment variable.
You can, however, use a target that simply updates the timestamp of conf.hpp, which will force it to always be rebuilt:
conf.hpp: confupdate
buildConfHeader $(CONF)
confupdate:
#touch conf.hpp
However, as I said, conf.hpp will always be built, meaning any targets that depend upon it will need rebuilt as well. A much more friendly solution is to generate the makefile itself. CMake or the GNU Autotools are good for this, except you sacrifice a lot of control over the makefile. You could also use a build script that creates the makefile, but I'd advise against this since there exist tools that will allow you to build one much more easily.
I have a repository for an application A which is controlled by mercurial and a library B which is also controlled by mercurial. In the application A's repository it has the sub-repository mapped to library B's repository using the path central repository path ssh://user#1.2.3.4/B. This works well enough for our internal development, but we need access externally, but we can't use the domain name as our router bulks. Is it possible to have the sub-repository defined as something like:
[internal]
B = ssh://user#1.2.3.4/B
[external]
B = ssh://user#domain/B
The only method that I was able to find, which sort of works, is to have each developer set the path for the repository. So for the example above, the path for an internal developer would remain unchanged, but the external developers would change their sub-paths to:
ssh://user#1.2.3.4/B = ssh://user#domain/B
I renamed a folder and updated my namespace declarations, but ReSharper 6 claims that the namespace should be a reflection of how it was before the rename. Where is it storing the file location data?
Check to make sure your assembly name matches your new namespace. If you've changed your folder structure to match your new namespace, you may still see the ReSharper alert until you update the project properties.
As delliottg's comment says, in Visual Studio, go to
Project > [project name] Properties > Application
and change "Assembly name" as well as "Default namespace".
I also had this problem with a folder/namespace and none of the above steps fixed it.
In my case I had to do this in Visual Studio:
Right-click the "problem" folder in the solution explorer to open the properties
Ensure the "Namespace Provider" is set to true
This fixed the ReSharper issue for me and I was able to adjust namespaces as normal.
Root namespace is needed to be changed as following.
I use Resharper 2019.3.2 in VS 2019 vs 16.5.2 and I had similar issues.
When developing, I first work out my namespace hierarchy in a single project, then split the project in seperate class libraries. In the first stage, it is convenient to always let the subdirectory correspond to the namespace.
For example, my prototype MeshTools.dll project currently contains:
Meshtools ........................ 3 cs-files in \MeshTools
MeshTools.HeightField .......... 2 cs-files in \MeshTools\HeightField
MeshTools.VectorTools .......... 3 cs-files in \MeshTools\VectorTools
The above answers all assume one single namespace per project. Renaming directories manually may confuse Resharper and that can be repaired by setting the default assembly in the .csproj file to the proper namespace. Thanks for the tip.
However in my case, I have several namespaces in a single project, with each namespace in a Solution directory corresponding to a real directory. Setting the default assembly "Meshtools" does not affect ReSharper behaviour for HeightField and VectorTools, when things have gone wrong with the renaming.
I googled this issue and came by https://www.jetbrains.com/help/resharper/Refactorings__Adjust_Namespaces.html#
It turns out there is a right-click option on a Solution Directory -> Properties. You will find an option to decide, if the Solution Directory is a NameSpace provider or not. When something has gone wrong, Visual studio will reset the field to False. Set it back to True and Resharper will correctly refactor namespace or file location when needed..
If you're using JetBrains Rider, go to the Solution Explorer and right click on the csproj file, then properties in the context menu. In my case the Assembly Name was already updated but "Root Namespace" wasn't, updating Root Namespace allowed JetBrains to automatically update all namespaces.