Is it possible to add custom tools to the TortoiseSVN menus? I'm looking to attach custom command-line tools or scripts (eg for our code-review system) such that they could be invoked against a filename, or repository URL, or against a revision number.
I've used other SCM tools (eg p4client) where you could set a command-template on either a path element (eg file/directory), or on a changeset (eg in the log viewer, or a pending changeset). The tool would simply substitute some special patterns with the path, changelist, or whatever as appropriate and blindly call the tool.
I'm not talking about commit/update hooks, its really about being able to browse the SVN history, select a change and fire off a tool-command.
Related
Hi DocuSign CLM geeks and the DocuSign API in-house team-
Our team will be using DocuSign CLM with the DocuSign Edit add-on to easily open Microsoft Word files and save back to CLM.
We'd like to include the installation of DocuSign Edit in our Silent Mode installation configuration. We're hoping there's an msi File available for the DocuSign Edit extension? If so, please link!
Plan B- If we were to make our own msi from the available exe, does anyone have a trail stomped out for doing this? (a blog post, documentation, step by step, video demo, even a horror story)
Thanks for tips.
https://tools.springcm.com/sites/default/files/apps/docusign-edit-pc-2.01.00.exe
This is an exe that is built from an MSI, so it is an MSI.
If you want to get the MSI out of this https://www.codetwo.com/kb/msi-from-exe/:
The first method is based on the fact that most installers extract their .msi files to the temporary files folder during the installation process. To extract an MSI file from an EXE installer, you need to:
Launch your .exe file.
When you see the first prompt (e.g. a question about whether you want to continue installation, accept a license agreement, etc.), do not click anything in this window and do not close it.
Open Windows Explorer, type %temp% in the address bar and press Enter.
Sort the files in the folder by the modification date. The newest file on the list should be the .msi file you are looking for.
Copy the MSI file to a safe location before you close the installer prompt window (see step 2). Be aware that if you close the installer window, the MSI file will be immediately deleted from the temporary files folder.
The second method uses a free third-party tool called 7-Zip to browse the content of the .exe installer file. Follow the steps below.
Download 7-Zip from this page and install it.
Right-click on the .exe file (from which you want to extract an .msi file) and from the shortcut menu choose 7-Zip > Open Archive.
Do not extract any files yet. Instead, browse and look for the folder MSI within the contents. It might take some time to find this folder because it is not always located directly in the root directory (its location may vary depending on the installer).
When you locate the MSI folder, you will notice that it most likely does not contain any .msi files, but a file or files with no extensions and rather cryptic names such as 132. Despite these misleading names, these are actually the MSI files you are looking for.
Drag and drop these files to any desired folder or select them and extract them with 7-Zip. Close 7-Zip after that.
Change the names of the extracted files so that they include the .msi extension.
If there are two files, the larger one is the 64-bit installer, and the smaller one is the 32-bit version. Use the one you need.
Finally, if you want to tweak an MSI, you can use the Orca tool by Microsoft - https://learn.microsoft.com/en-us/windows/win32/msi/orca-exe
My favorite editor, geany, has an option "Disk check timeout", after this timeout it checks if someone else has overwritten the file that I'm editing. This is a simple tool to detect if two people work on the same file (we don't use a version control system). Is there an option or a plugin for kdevelop that does the same thing?
Edit: as Zhigalin said KDevelop does the check automatically but only for local files, I need it for files opened using sftp.
In KDevelop this check is always active, you will get a popup as soon as you focus on that file in the editor.
Edit: if you are speaking of remote files than the reply is no, there is no such functionality.
So you have 4 options:
File a proposal here (which probably won't get implemented soon because of few active developers)
Patches are always welcome
[suggested] Start using a version control system like Git, there are even tools to automatically deploy on server when you make commit on a specific branch.
Use AutoFS(FUSE) to mount your server as a local folder.
I'm fairly new to TFS, coming from a a CVS and Subversion background, with some Git and Mercurial influences. I find that I am often fighting with it because it doesn't compare the state of your working copy on the file-system with that in version control. Instead, it shows you what it thinks is the file system state, based on what you've done in Solution Explorer and Visual Studio.
For example, if you delete a file in Solution Explorer and, later, replace the file in some other tool (usually Windows Explorer) TFS will insist that the file is deleted. Further more, it will 'detect' the replacement and suggest it as an 'Add' but it won't let you promote that because the 'Add' conflicts with the 'delete'. There is no easy way to resolve this because you can't undo the 'delete' either - you can't undo a 'delete' if the file is physically still present on the file system!
This, in my opinion, is a disaster. Why can't it just forget what you have previously done in Solution Explorer and show you the current state: i.e. the file has merely changed (or remains unchanged.)
Similarly, if you edit a file in Visual Studio and subsequently edit it to undo those changes, TFS insists that the file has been modified, sometimes, even if there are no effective changes - the committed revision is identical to the new one after your changes.
Is there any way to break this link and disable tracking of you actions inside Visual Studio - i.e., when you refresh 'Pending Changes', it looks at the current state of your working copy on the File System and diffs THAT with the head revision?
If you're using TFS 2012, you could use a local workspace: this uses the local file system in a way more analogous to SVN, although it may not match it in every way..
Note that if you have more than 50,000 items in your workspace, this is not advisable due to performance considerations.
This doesn't have anything to do with Solution Explorer, per se. Team Foundation Server, when it operates in "Server Workspace" mode is a checkout/edit/checkin type of source control system. This means that you must explicitly inform the version control system that you are making changes. This allows it to scale to very large repositories, since it does not have to scan the filesystem, like an edit/merge/commit (like TFS "Local Workspaces" or Subversion) would, or like a distributed version control system (like Git) would.
Visual Studio or Eclipse will interact with the source control system, so that when you start editing (or delete, etc) a file then it will inform TFS of your changes so you do not need to make these changes manually. If you interact with your working copy from another program (Windows Explorer, Notepad, etc) then you will need to manually pend those changes with the tf command-line client or with Source Control Explorer.
If you find this frustrating and do not require the scaling abilities of TFS Server Workspaces, then you can use a TFS Local Workspace, which will scan the filesystem and notice any changes you make outside of your IDE. Or, of course, you can use the Git support built in to Visual Studio and TFS 2013.
I have a solution with two projects. I just marked the solution and checked it in and now all files have that little image of blue padlock on the left side which obviously means that they are marked as read only.
I've been working only with Tortoise SVN till now and this is my very first check in to TFS, so why does this happen, or if it is too complicated for an answer here, at least how can I return the state of my files (the entire solution maybe) to normal.
Also I've been struggling to find a good reading/tutorial on how to use/execute the basic tasks for TFS from Visual Studio 2012 so if someone can share a good source of information about the topic it would be much appreciated.
This is, in fact, normal. You are using a "server workspace", or connecting to a TFS server from before TFS 2012. Team Foundation Server has multiple modes of working:
A Checkout/Edit/Checkin system (via "server workspaces") means that you will need to explicitly check a file out to begin editing it. Files are kept read-only in order to indicate to you quickly what files are checked out and which files need to be checked out. If you simply start typing in an IDE or editor that understands TFS version control (Visual Studio, Eclipse) then the IDE will check the file out for you. Otherwise, you will need to check the file out manually (by selecting "Check Out for Edit" in Source Control Explorer or by running tf checkout <filename>.)
This type of system is very useful with teams that have very large repositories or very large files in those repositories; by explicitly instructing the source control system that you are editing a file, you avoid the need to scan the filesystem.
An Edit/Merge/Commit system (via "local workspaces") means that you do not need to take any explicit action to check a file out, when you query your pending changes, the disk will be scanned to determine what changes you have made. Local workspaces are the default in TFS 2012, though you or your administrator may change this default.
This is similar to the way Subversion operates and is generally suitable for most repositories, however if you use keep large binaries in your tree, it is probably not a good option.
A Distributed Version Control system (via git) means that you have a complete clone of the repository locally and allows you to work completely independently while offline and share your changes or receive other peoples changes as you see fit. Git is new in TFS 2013 and Visual Studio 2013.
This type of system is very useful for highly distributed teams and teams that want to take advantage of novel branching strategies but may not be appropriate for teams who have very complex requirements around fine-grained permissions.
If your server is TFS 2012 or better and you want to convert your existing server workspace to a local workspace, you can open the "Edit Workspace" dialog and in the advanced settings, change the type of your workspace. This will make all your files writable and you will continue working in a Subversion-like mode.
this is quite normal, having locks to the files.
However, you can set the level of source control of different check in / check out strategies.
link: http://msdn.microsoft.com/en-us/library/ms181237(v=vs.90).aspx
For the global documentation :
Source control : http://msdn.microsoft.com/en-us/library/vstudio/ms181368.aspx
Tfs global : http://msdn.microsoft.com/en-us/library/vstudio/hh529827(v=vs.110).aspx
I have a larger solution that I desire to distribute via ClickOnce. It consists of one main shell executable that directly references only a small subsection of libraries and processes that constitute the solution.
The solution consists of a few other processes and several libraries (some C++). I need to be able to include all of these libraries and processes in one ClickOnce distribution for both local builds and TFS server builds.
I cannot reference every other library and process form the shell project. And I do not wish to push these files into a MSI to be treated as a prerequisite as it would defeat the purpose of using ClickOnce to distribute/update the product.
What is the correct method to incorporate all of our necessary files/projects into a single ClickOnce distribution?
The IDE won't detect native DLLs as dependencies when publishing, but you can run the SDK tools directly to include them manually in your ClickOnce distribution. You can either use mage.exe in your post-build script or run MageUI.exe to have a wizard to guide you through the package generation.
Suggested reading:
Walkthrough: Manually Deploying a ClickOnce Application
Understanding Dependencies of a Visual C++ Application
There is an alternative to Visual Studio for this kind of situation. You could try using Mage, but it can be a little tricky to use. My company wrote an alternative called ClickOnceMore.
ClickOnceMore is a ClickOnce build tool for when you don't want or can't use Visual Studio to do ClickOnce builds.
There is a specific page on the UI for including files (using rules to include anything from a single file to an entire directory trees) so you should be able to do exactly what you need with it.
This is what I have done in a similar situation. I use TFS at work, so convert the terms to whatever you may use (or not use) for source control.
I have a main workspace that I use for all development of my application, I keep this workspace pristine.
I then created another workspace with a proper name (ex: solution-deploy) and in this workspace I do the following:
Get latest and merge everything from source-control into the deployment workspace
I build a Release build of my application
I r-click on the root (I put them in the root, because I need to access them from there, put them in whatever folder you want) project folder for my deployment project and select "Add -> Existing Item"
I browse in the file selector to the Release directory of the assemblies I want to add to my deployment package, select them, then I use the arrow next to the Add button and drop down to "Add As Link", do this for all of the assemblies you want to add and place them wherever you want them to be organized in your deployment
In the Solution Explorer, select the added assemblies and in the Properties window set the Build Action to "Content", this should be all you have to do, but others have had to also set the "Copy to Output Directory" to "Copy Always", I don't do that
Run a Release Build
Go to the Properties view for your deployment Project
Go to the Publish Tab and Click on the Application Files button
Your files should all be available and added to the Deployment
Set up your ClickOnce settings however you need them to be
Publish your ClickOnce package
Your published package should contain all of the assemblies you need now.
Keep your separate Deployment workspace set up this way and never check it in. Do your work in your development workspace. Whenever a new deployment is needed, open your solution in your Deployment workspace and get the latest code, build, then publish.