I have a Web API project in TFS it contains all files including edmx files and
connection string in webConfig
When I cloned the project all files are exist in my local machine except the edmx files and connection string.
Why those files are not coming? I tried to get the latest again and they're still not cloned.
Shall I add the Data(ADO.net) manually? is it correct way to do it? and why it's not getting cloned?
Please check with the following things:
How did you clone the repository? Using VS, or git clone command, or other methods? Please try different methods to see if the problem still occurs.
Check whether the .edmx file was added into the .gitignore (if any). If yes, remove it from the .gitignore.
Whether the ADO.NET Entity Data Model project was created by you? If it was created by other people, you need to confirm if the creator has set blocking other user to check out the specific files.
Related
Wanted to ask this bluntly as I can't seem to find the answer out there.
When I run 'Add-Migration...' 3 new file migration files are created (.cs, .resx, .Designer.cs). In regards to source control, which files should I commit to my repo and what files can I ignore? I'm only interested in the files absolutely necessary to reconstruct my tables if needed.
When I run 'Add-Migration...' 3 new file migration files are created
(.cs, .resx, .Designer.cs). In regards to source control, which files
should I commit to my repo and what files can I ignore?
All 3 files are necessary to reconstruct your database.
the .cs file contains the Up and Down method to help you, respectively, updgrade or downgrade your database.
the .resx file contains the metadata that is used by migrations. It contains the name of the default schema you use (dbo is the default value) and a snapshot of the model at the time the migration was generated.
the .Designer.cs is here because of the presence of .resx. It contains properties that make easy to access settings on the .resx file.
All 3 files need to be committed and pushed in your source control and no one should edit them.
I am using Subclipse, though my working copy is up to date I get the following error when creating a tag:
You should not be confused about the error message. the file part in file:/// does not mean that test is a file. It's an indication that the repository is located on the local storage support (file system).
However I have to admit That the error message isn't enough explicit in the part already exists. The solution to this issue is to create the tag into a non already existing folder.
In other words you should not create the folder that will hold your tag before this step (using New Remote Folder in view SVN Repositories). The folder should be created at the moment of the tag creation. This is done by adding the new folder (e.g tag-folder) to the URL i.e file:///C:/Users/tunnaruto/Dropbox/Studies/pfe/repository/fo/test/tag-folder and don't forget to check Create any intermediate folders that are missing.
I erroneously shared a locally developed project into trunk. I deleted it in Eclipse SVN Repository Exploring view. It no longer appears in the repository view. Then I tried to share the project into the correct branch and I get this message:
The project "Project1" already exists in repository and has some
content. To connect the local project to the specified location, the
repository folder content should be checked out. Please consider that
applying local changes can cause resource conflicts. For example, if
the local file has the same name as the remote directory the working
copy of the file will be obstructed.
Do you wish to proceed ?
There is no project with that name in SVN that I can see.
After trying unsuccessfully to find any references to this message I chose yes for proceed. Then it looked like it was uploading multiple projects and files that didn't belong to this project -- the title on the dialog box was Share Projects rather than Share Project as well -- so I pressed cancel.
Anybody know what is happening here?
I have a configuration file in my project which needs to be in the repository (so new developers get it when they checkout the project). Each developer might change some values in the file locally - these changes should not be committed and I don't want them showing in the synchronization menu (I'm using eclipse and subversive if it matters).
Note that I can't just set the svn:ignore property since it only works on files that aren't under version control - but I do want to keep a base version of the file in the repository. How can I avoid the file showing in synchronization without deleting it from repository?
EDIT: A better description - what I actually need is to be able to set a "read-only" property on the config file, so it can't be changed in the repository as long as the property is on. Do you know anything like this?
Thanks
I do this by having a base version of the file checked-in as foo.base, and svn lock this so that it's read-only on checkout. Then have each developer copy this file to their own personal foo file, which is ignored by svn-ignore.
You can't ignore files which are already under version control. The only way to ignore such files is first delete those files do a commit and after that change the svn:ignore property and do a second commit.
If you like to have a kind of Base-Version use a template which has a different name.
You can version template under different name
OR
Read this answer
once u check out, u can lock it, and once it is locked, others will not be able to commit(make changes to svn) that file. see image below
My solution is that a compile time script creates a copy from the original template file if it does not exist. This copy can be put on the ignore list. I feel that locking a file for this purpose abuses the locking feature (it was not created for this).
I have a setup as follows.
A private repository at bitbucket where I keep the 'master' repository.
A repository on my server which acts as the 'live' website.
A repository on my laptop which acts as my working copy.
My process is as follows. I make a change to a file in my local repository. I commit these locally. I push these changes to bitbucket. I then pull these changes from my bitbucket to the webserver.
The problem that I have however is that my local copy utilizes different configuration settings for databases, paths etc, ergo what I want is my 'config.php' file at bitbucket to contain the server settings, and the config.php on my local host to contain local settings.
I believe this can be achieved with .hgignore but i have had no success researching.
The problem i encounter is that i make my server settings file, push it to bitbucket, 'forget' the file in my local repository, create a .hgignore, and then recreate the file. However when i 'forget' the file TortoiseHG notices and asks me to commit the change to bitbucket....
Any ideas would be greatly appreciated.
Thanks
Additional Points.
Following the advice below I have developed a setup as follows:
I have my local repository on my laptop where i do my edits.
I have bitbucket which is essentially the 'main' repository - if any other developers join the team they clone this.
I have my live repository on my web host.
On my live repository I have a .hgignore file whichs ignores the respective config files.
As such when I do hg pull from my host, it pulls the repository as is with the localhost configuration files, but when i type hg update (to the live working copy), these files are ignored/not updated.
Could someone clarify as to if i have understood this correctly, and as to whether this is a suitable way of achieving what I want?
Thanks
.hgignore only ignores files if they are not versioned already, so I don’t think your idea in the question will work.
The common approach regarding local configuration is generally a variation on the same theme, like of one of the following:
Do not check in the config.php at all. You can check in a config.example.php with the most common settings, and document in the README that users have to copy it to config.php and then edit it.
Put any shared settings in config.php, and add an include statement to point to an unversioned file with settings specific to the machine, e.g. config.local.php. You can also provide an config.local.example.php-file for this.
Like 2, but the config.php contains all default settings and the local file has the ability to override them.
Check in a config.dev.php and config.server.php-file containing the settings for both environments, and then have an unversioned config.php which includes one of the above files. Advantage is that the configurations themselves are versioned and you can update them.
Which of these variations to pick, or whether you make another variation, depends on your environment.
The basic idea for working with version control and different configuration files is always the same, but I don't know enough PHP to give a detailed answer how you can do this in PHP.
I answered a similar question for .net/Visual Studio a few months ago, so I'll just give you the link to this answer and try to describe the basic idea again, but this time language-agnostic:
For your use case, the basic idea is to have two config files in the repository, one with your local data and one with your server data, for example like this:
config.local.php
config.server.php
The "real" config.php is not in the repository, and it should be in .hgignore, so it never will be in the repository either.
After pulling, you need to run something that copies one of these files (the "correct" one depending on the current environment, local or server) to config.php.
And exactly this last part is the part that I can not answer in detail, because I don't know how to do that in PHP and/or on a web server because I'm a .net/Windows guy.
As far as I know, deploying a PHP site is just copying the files on the web server, so there is no "build/compile" step where the copying/renaming of the config file could be done (where I would do it in .net). Correct me if I'm wrong...
EDIT:
Thomas, I'm not sure if I understood your edits correctly. Your "local" repository on your laptop and your "live" repository on your webserver are basically clones of your "main" repository on Bitbucket, correct?
If yes, are you saying that you have different .hgignore files in the different clones?? That's the part that confuses me.
No matter how you actually do it in the end (there are several possibilities to deal with configuration files, see below), the .hgignore file should be the same in all clones of your repository.
So all your repositories (no matter which clone on which machine) should all contain the same configuration file(s).
Then, you only need to make sure that different configurations are used in different environments. There's already an excellent list of different ways to achieve this in Lauren Holst's answer, so I'll just point you there.
As Laurens Holst already said, we can't tell which of these ways is the best for you - it depends on your environment.
You might want to check here. If both the config file and .hgignore are commited, the .hgignore will have no effect. You could also add a domain check conditional:
$domain = $_SERVER['HTTP_HOST'];
if ($domain=="localhost") {
//local copy config
}
else if ($domain=="yourdomain.com") {
//webserver config
}