I am working on a new project with three other developers, we are all new to Mercurial.
A post build event is created in Visual Studio 2010 to copy DLLs to a common folder. Each time anyone commits or updates we want to rewrite without considering version or merging. That is, this particular folder overwrite local working copy on each update.
Is it possible?
The conventional wisdom is that you shouldn't be committing build products at all. You version source code not dlls. Those you download during build from your CI system.
That said, if they're all DLLs you can set a custom merger for those:
[merge-patterns]
**.dll = internal:remote
That always uses the "other" version when there's a conflict on .dll files. More details here.
Perhaps mercurial hook is the answer.
It is possible to create post commit or post pull hook which will do some work, in this case copy files to common folder.
However, if you wish to copy file after each build, then mercurial is not the way.
In that case, build tool should copy the necessary files.
Related
File templates for WebStorm can be placed in the config/fileTemplates directory of the local WebStorm settings folder.
In addition to the templates stored there, I have a couple of file templates for our project that are in the project SVN repository. I want WebStorm to also offer me these templates.
Is there a way to tell WebStorm to use a specific folder in my working copy on top of the usual fileTemplates directory?
I could find some hints, but they appear to be dead-ends (or maybe I'm missing something):
The documentation on sharing templates makes this sound very manual (as in, moving files around). This is not a viable approach, as the template files might be updated any time. I do not want to preemptively copy the files around after each of my daily working copy updates, just in case on of them has changed (nor do I want to watch out for changes to the templates folder - I want WebStorm to catch up on these udpates on its own).
The article on file and code templates refers to per-project templates that "can be shared among the team members". This sounds like the right thing, except that they have to be placed in the .idea folder (the folder with the project file(s)). As I'm working on a huge project with many submodules, each team member (of several dozen devs) is only interested in a different subset of the overall project, so everyone has their own .idea folder that is not committed to version control.
The article on project and IDE settings indicates that (only?) "Locations of the config, system, plugins directories can be modified in idea.properties file."
I need to work on a repository which is in a Git, I want to know how to work with a project inside the repo in the vivado? I googled it and found that I need to address ".tcl" file in command terminal but, in my "sample project" folder there are multiple ".tcl" files so I got confused if I need to add all of them or not.
Vivado is NOT git friendly and you will need to go several hoops to get it even tolerable.
First, generate tcl script to regenerate the project:
write_project_tcl create_project.tcl
This file can go to git and can be used to generate the project after a clean clone. To be noted that this is not the project file, it's a script that can re-generate the project. So running it every time a project parameter changes is quite cumbersome, and often leads to situation where local projects veers off from the "template" project in git.
Another problem is Vivado generated IP. Fortunately most often you need only the .xci file from the generated files to be stored in git. Unfortunately, by default these are generated as part of the project files, which should not go to git. I would recommend putting the generated IP to some other folder outside the project-structure. Vivado will fight against you on this, but mostly it's worth it.
Our team of 4 currently uses svn, but I am testing out Mercurial. We code mostly in C++ and C# on .net. I have installed TortoiseHg, and use hgsubversion to push/pull against the existing svn repo. Other developers on the team will remain on svn for now.
I tend to have a few source files that I have customized (butchered would be a better term) in some specific way that I don't want to push to other developers. But I do want these custom changes compiled into my version of the project. The ratio of normal files to customized files is about 100:1
What is the best way to deal with these butchered files in mercurial? I could simply uncheck butchered files during commits, but eventually, I will forget this step. I have taken a brief look at shelving and ignoring.
Ignoring doesn't seem right, because these are tracked files. I do want to pull changes to butchered files from others. Shelving was close, but it removes the butchered code from my working copy, so that isn't correct either.
I can't be the only code butcher out there. Let me know how you deal with this. Git users, we are happy to hear from you too, we haven't entirely committed to using hg.
If they're files most everyone will be modifying (per developer database account info, etc.) the right way to do it is by tracking a xxxxx.sample file. For example have the build script use local-database.config which is in the .hgignore and provide a local-database.config.sample file in the repository. You can either include "copy the sample to the actual" in your instructions or have the build script do it automatically if the actual doesn't already exist. We have our config do a include of settings.local if and only if it exists, and allow it to override main settings. Then no one needs a local config, but it can be optionally used to alter anything w/o a risk of committing it.
If they're files that only you will be modifying the best way is to learn Mercurial queues. Then you can pop that changeset with the you-only changes, push to central repo, and then apply it again for your builds. There are various extensions that do similar things (shelve for example), but mq is preferable because you can version the overlay you're popping and applying.
My team is switching to Mercurial. Our projects all have a config file (web.config or app.config, and a few bat files as well - we are a C# shop). These files need to be part of the repository. When a developer clones the repository, local changes are needed to their config files to get them working. For example, a project's config file may need a connection string to the developer's database, or other environment-specific info. We don't want these changes ending up in the repository. And from time to time we do make changes to these configs that do need to get into the repository and distributed to the team and eventually the customer.
What is the easiest way for us to configure or use Mercurial so that these files are not getting committed by accident? I would like to be forced to make an explicit commit of such files, yet merges from the repo would automatically come down in updates.
This has to be a problem someone else has faced, but as Mercurial newbies we are all at a loss for the best solution.
Edit:
A similar question that may share some common solutions, but is not the same as this question, can be found at: Conditional Mercurial Ignore File
I am including this in case that other question might provide the answer you are looking for.
The typical way to handle this is to store templates for the configuration files in your repositor, and add the actual configuration files to the ignore list in Mercurial.
This way, you have pristine, unmodified, copies of each configuration files available at all times, even for new developers who clone from scratch, but in order to make the configuration files usable, you need to make a local copy of it to the actual configuration file name, and modify the file. You could also use compare/merge programs, such as Beyond Compare, to compare a new version of the template file with your local copy of an older version, to see what changed, and add in the missing bits.
If you need to hard prevent committing the actual configuration files, you need a pre-commit or pre-push hook that does this.
In your .hg/hgrc file do this:
[defaults]
commit = -X Projectname/web.config
(assuming "ProjectName" is the project subdir)
Edit:
Also, if you're using Tortoise HG - add this as well:
[tortoisehg]
ciexclude = Projectname/Web.config,Projectname/App_Data/DBFile.mdf
(by the way mind the FORWARD slash in folder-path! Even on Windows!)
I'm trying to sell our group on using Mercurial as a source repository rather than VSS. In the process of updating our build scripts, I'm running into an issue trying to retrieve files from the Hg repository.
Our builds are automated with NAnt and currently work for local builds or builds from VSS (ie, pull the source as needed from VSS). I'm trying to update them to work with Mercurial as well.
Basically, when I'm working with single files, I don't have any issues since I can just use NAnt's 'get' task (after getting the appropriate revision hash) to retrieve the individual file.
The problem that I'm having is when I need to work with a directory (and subdirectories) of files that aren't at the root of the repository. I can't seem to figure out the proper commands to retrieve/copy a subdirectory from the repository to my 'working' directory for the builds. I've spent basically the whole afternoon trying to figure out how to do this with the mercurial executables (so I can use a NAnt 'exec' task), and have basically hit a wall so I figured I'd try posting here.
Can someone confirm whether this is possible, and provide some suggestions as to how I might be able to do this? I realize that Mercurial tracks changes by files and not directories, but it seems odd to me that this isn't available out of the box (from what I can tell).
If it's just not possible, the only workarounds I see are either maintaining NAnt fileset lists of expected files to work with (ugh!), or cloning the entire repository to a temporary directory and then just copying the files from that source as needed (this feels like a cludge to me).
I realize that I could simply create another repository for the directory that I want to work with, but I'd prefer to not go that route since I think that would increase the complexity of what I'm trying to do by a significant amount (I would have to apply this a large number of times for all of the different libraries that we build..).
Mercurial doesn't let you get only part of a repository. You have to get the whole tree. It's much more whole-repo focused than svn is.
You could try and segment your repository into multiple repos and manage them using the subrepos feature. Then you can pull the subdirectories independently.