I'm trying to create a client hook script for TortoiseSVN 1.8.11 on Windows 7.
What is givining me trouble is the path to the hook script in the settings (Settings->Hook Scripts).
Using the absolute path to my batch script works, but I need to use a path relative to the repository. The reason for this is that coworkers might have their repositories in different locations and the hook script should be used by everybody. Server side hooks are out of the question, since I can't modify the server.
I tried using environment variables, ^/my/path/hook.bat and ^^/my/path/hook.bat, no success.
Client-side hooks are local executables, not related in any way to your local Working Copy (not repository)
TortoiseSVN's configuration, performed using TortoiseSVN - Settings, not stored in WC|repository and also is pure local
If you want to have any client-side hooks avaliable and callable for everybody in team (with TortoiseSVN only), you have
Place these scripts into repository
Define all hooks as folder-properties in repository. Read about
tsvn:startcommithook
tsvn:precommithook
tsvn:postcommithook
tsvn:startupdatehook
tsvn:preupdatehook
tsvn:postupdatehook
properties and parameters and about using special wariables (%REPOROOT% and %REPOROOT+%) in script-path in TSVN help, part "4.17.2. TortoiseSVN Project Properties"
Related
i am using hybris version 2005
I installed addon with this command
ant addoninstall -Daddonnames="notificationaddon" -DaddonStorefront.yacceleratorstorefront="myStorefront"
How can I run adon without using this command on all devices? Where should I add what settings
Afaik there is no need to install an addon on all "devices", the addoninstall call changes two files in the destination extension e.g. the storefront extension:
myStorefront/.classpath
myStorefront/extensioninfo.xml
These files are usually under source control, so if you commit them, every time the project is built there is an ant macro that copies the addon into the extension directory.
Additionally, the addon should be added to the localextensions.xml, usually there is an template for the local dev env and the production, both should be updated.
I understand by devices, you mean the servers? If this is right, then you do not have to run this on servers. Instead, let the CI script take care of this. Based on the deployment strategy, your script would automatically run this command and the addons get installed on the storefront.
Every Addon does different work and requires a different way of inclusion.
The add on has a file project.properties.template that contains the properties that become active once you install the addon.
The addon has build.xml that is used to build that along with the storefront extension, whenever called back.
The source code including the java and XML that gets compiled along with the storefront. An AddOn can override any resource in the storefront extension.
For further information, please visit the Addon Concept illustrated in SAP help portal.
I've searched in haxelib for a library to use for remotely editing a file on a server using ssh connection with haxe, or listing files in directory..
Has any one done this with haxe?
I want to build a desktop app to create a yaml editor that will change settings files of several servers using a frontend like haxe-ui.
Ok, there are probably a lot of ways you could do it, but I would suggest separating your concerns:
desktop app to create a yaml editor
Ok, that's a fine use case for Haxe / a programming language. Build an editor, check.
change settings files (located on) several servers
Ok, so you have options here. Either
Make the remote files appear as local files via some network file system, or
Copy the files locally, edit them , and copy them back, or
Roll your own network-enabled service that runs on each server, receives commands, and modifies the files.
Random aside: Given that these are settings files, you probably also want to restart some service after changes are made.
I'd say option 2 is the easiest. There are even many ways to do that:
Use scp to both bring the settings files to a local location, edit them locally, and then push them back. And if you setup SSH keys, you won't have to bother with passwords.
Netcat is another tool for pushing bytes (aka files) over the network. It's simpler than scp, but with no security measures.
Or, get creative / crazy, and say, "my settings files will all be stored in a git repo. The 'sync' process will be a push / pull setup."
There are simply lots of ways to get this done.
I'm working on 2 different machines (home vs. work) and transfer the code via GitHub, which works nice, but I just ran into a machine dependency when I added this code to the gradle.properties file to fix a vexing OAuth issue for google sheets:
org.gradle.java.home=C:\Program Files\Java\jdk1.8.0_131
org.gradle.java.home=C:\Program Files\Java\jdk1.8.0_77
Now I have to toggle between the 2 lines to get Gradle to compile. Need to check if I still need it (since I got the keystore files etc. sorted out), but I also wonder whether there is an easy solution to make this work (e.g. something like ifdef).
Obviously, I could just change the directory name in one of the machines I guess, but still curious how to solve this within Studio.
Lets start with a quote from the Gradle docs:
org.gradle.java.home
Specifies the Java home for the Gradle build process. The value can be set to either a jdk or jre location, however, depending on what your build does, jdk is safer. A reasonable default is used if the setting is unspecified.
So, by default, you should not need this project property (thats what they are called in Gradle).
However, there can be reasons, that you need to specify the Java directory. For this specific project property, you can follow Ray Tayeks advice and use the JAVA_HOME environment variable (on both systems). But there is also another approach, which can be used for any project property (and also for so-called system properties):
gradle.properties files can be located at different locations of the file system. Your files are located in the project directory and, therefor, they are included in your VCS. You can use them / it for project-related properties. An additional location is in the Gradle user home directory, which is by default the .gradle folder in your personal folder. This folder is not under version control, so simply define the property there.
try removing the line from the properties file. if that fails, try setting JAVA_HOME on each machine.
there are a lot of related questions.
you might try asking on the gradle forums.
we are testing a setup to automate building of NSF's using headless designer.
when a developer pushes a change to a repository on github ultimately this will result in an update of an NSF that resides on a Domino server.
local odp -> github -> local nsf with headless designer -> replace design nsf on domino server
however we noticed that the process stops sometimes. as far as we can see headless designer cannot "copy" (or translate) the design elements from the ODP into a new local NSF. so only an empty skeleton NSF is created.
we noticed that the stop does NOT occurs when the name property in the .project file of the ODP has changed.
so somehow it looks as designer still has the ODP in memory and does not notice any changes, unless it "finds" a "new" project via the project description "name".
anyone experienced something similar ? or recommendations how to start designer without any cache?
An (in-?)elegant solution which I use, since I want to keep things tidy and separate for each build, is to compute a unique filename for the NSF. This will create a separate NSF for each build and while it will retain things like the Application name and template name, it is unique in enough other ways to not cause issues for the DDE headless build.
Defining in CI Config
]1
Using Env Vars in PowerShell Script
For example, I use an app specific prefix, defined in my GitLab CI config, which then is used with the unique build number (both set as environment variables), which my modified version of Egor Margineanu's PowerShell script picks up for the build.
Bottom Line
The unique namespacing means no conflict from DDE's perspective.
I'd like to set up a commit hook that will subsequently upload source files from a Windows environment to a Linux server, which is not the same as Linux server running SVN.
I'm familiar with setting up client side hooks, but not sure what the script should be like.
I'm not really sure the easiest way to go about this. I'm thinking a Windows script that will run a copy command that can do this sort of thing. My entire group would use it so the script would have to be located on a Windows NFS. Ideas?
not sure what the script should be like
Client-side (as server-side) hook is any program, which can be executed on this host. Single difference between these type of hooks is location, where program is executed - clent-side hooks of TortoiseSVN will run on developer's host with Working Copy
Your script must be non-interactive set of operations, which will perform needed operation (ssh or ftp to target host, upload files) - can't see any problem here (except one - FTPing a bundle of /random/ files is always a big headache)