I am trying to write a simple app in C# for source controling database files using SharpSVN library and have some problem implementing atomic commits.
This is the workflow i have in mind:
User changes some files in database locally
Compares to source control and checks some of the changes for comiting
Loop through all selected changes (could be: add file, modify, delete) and apply them to the SVN working copy
If everything is succefully applied to working copy, call commit, else revert all
If commit is unsucesfull revert all
I am adding files to local working copy by calling File.Copy(temporaryPath, workCopyPath) and then SvnClient.Add(workCopyPath)
I am adding modifications to local working copy by calling File.Copy(temporaryPath, workCopyPath)
I am removing files from local working copy by calling SvnClient.Delete(workCopyPath)
In case of error while applying changes to working copy i tried to revert to the state before changes by calling SvnClient.Revert(workCopyRoot)
but that does not revert all changes (for example, added files are still in workin copy after revert).
If everything is ok after applying changes, i call SvnClient.Commit(workCopyRoot) to apply changes to remote repo.
Is this a proper way to apply changes to working copy or should i use something else?
Should i monitor changes to working copy and revert them manually (without SvnClient) or i am just missing some parameter for the SvnClient.Revert() method?
Thanks in advance, any help is more than welcome
Related
For example I am working on some file.
I want to mark it like a file for the future commit and i want to do it right now because I will have many files and I can't remember all changes in them.
And right now I have no access to TFS (I need to connect to VPN to get access to TFS).
Is there any way to mark a file?
TFVC does not support offline work in the same sense as a true distributed version control system like Git.
With local workspaces, you can modify files without checking them out first. They will appear as pending changes, but you won't be able to check the changes in until you have connectivity to the TFVC repository.
When files in a tfs workspace are moved outside of tfs (eg. through windows explorer), tfs picks these moves up as a delete and an add.
To get around this, I have a program running that monitors for changes and when a move happens I do a Workspace.PendRename with updateDisk set to false.
This works fine except that tfs adds the delete as a candidate change.
Is there anyway to remove this candidate change? It causes issues if people try and promote these changes.
By using Workspace.GetPendingChangesWithCandidates I can get the candidate change, but there doesn't seem to be anything I can do with it to remove it from the list.
Before doing the PendRename, I tried moving the file back to it's original location (File.Move) and then doing the PendRename with updateDisk set to true. This actually works well for single files, but gets complicated when folders and such are involved.
I'm hoping there's a simple way to either remove the candidate change from the list, or to even disable the candidate changes functionality altogether for certain files/folders. I tried adding the folder to the .tfignore file but that doesn't work.
Promote Candidate Changes shows deletes even though files were renamed
In TFS there are two kinds of moving files. I have crated a sample for both :
Local Workspace (window exploer) directly move/drag file
In the disk my workspace, I'm going to move 2.PNG to Main-branch
folder
Then we could check what TFS detects in VS. One with add(in new
place), one with delete(in old place) in Promote Candidate Changes.
You need to check in both the add and delete ( promote first). Finally
you will get what you want both server and local.
Move a file in solution explorer directly
In the solution explorer , I'm going to move 1.PNG to Main
folder by right click and select move.
You will get a pending change with rename status directly and
not any Promote Candidate Changes.
Then we could check our local workspace, you will see 1.PNG is
automatically deleted in the workspace folder even though you haven't check in changes. Finally checking pending
changes, everything is fine and clean.
Back to your question: Promote Candidate Changes shows deletes even though files were renamed.
The TFS API should be using the way 2 above. Look at the parameters :
updateDisk
If true, the local disk is updated according to the pending changes;
if false, the disk is not modified and changes are not
acknowledged.
So if you set the updateDisk to false , the 1.PNG should still exist in the disk and TFS detect it and adding to promote Candidate Changes shows deleted. Which meets your screenshot. The solution should be change the value from false to true.
When I delete and re-add a file in Visual Studio, which is under TFS-SourceControl, if I check in, the TFS only detects the Delete, but not the add.
Since we trigger a "Compile"-Check after each checkin, this always triggers an error, since the newly added File is not found, so we have to check-in twice.
Is there a possibility to tell the TFS to mark the deleted/added file not as deleted, but just as changed?
What exactly are you trying to do? If you delete the file, TFS will set the state of the file in source control to "delete pending". It isn't possible to then change the state of the file again to something else without either first checking in the pending change or undoing it. Delete and Add are incompatible pending changes on the same object.
Surely if you are deleting then re-adding a file you are in effect making an edit change, which would be properly tracked in the history. Why not check the file out for edit and assuming the new content is radically different from the original, overwrite the checked out file with the new content and then check it back in.
select the files that don't have the blue lock icon next to them and open the context menu and add them to source control (include in project) then Pending changes will see them
For me the issue was with re-added Table in Entity-Framework.
In EF DB-First when changing column definition in DB, EF does not detect any change or when removing a column. (ex: when making a column nullable)
This is only fixed by removing and re-adding the table in the edmx.
TFS only detects the remove, not the add of the table's .cs file. Then TFS doesnt let you revert the delete because "file already exists"
This can be fixed by opening the local CS file in a text editor to save the current generated code (1. save the local cs class), then delete the file (to match the tfs state) so that you can revert the delete in the pending changes (2. delete the physical cs file) (3. revert delete in the pending changes window), then manually replace the reverted cs file code with the one saved in the text editor (4. manually update the cs class with the code saved in '1'). Review and Commit your changes.
I'm trying to get one of our internal c# click once applications into VSOnline for source control to allow access for an external developer.
I think I've got it set up and working in the Source Control Editor, but am having trouble working through how to actually use the setup day to day.
I've got some git experience but zero TFS experience, but went with the TFS option as I thought it's more likely developers are familiar with it than git.
What I'm trying to achieve is 3 branches; Main/Trunk, Dev and Release and be able to deploy at least Release and Main. Release is for external clients, Main for internal clients.
At the moment my Source Control Explorer looks like;
DefaultCollection
-->Name of project
---->(Branch icon) Dev (created as a Branch from Main)
---->(Branch icon) Main
---->(Branch icon) Release (created as a Branch from Main)
2 things;
In terms of use I'm not really sure how to swap between the branches for coding / making changes? Do I just open the solution file for the branch I want to work on then save all changes as I go, then commit that as a changeset? Or is it a matter of manually checking the file out, working on it, then checking it back in again?
Given it's a ClickOnce app; each branch is deployed to a different IIS site, meaning diff app identies, paths and settings. Am I right in using branches for this or is there a better way? I'm worried about someone committing the wrong file and causing a mandatory uninstall/reinstall of the app.
Any pointers / docco greatly appreciated; just note I'm using VS2010.
Thanks,
Liam
How do I swap between branches
If you're used to GIT than the 'heavy weight' branching in TFVC can be a bit confusing. There is no real "Switching between branches" as you've encountered. You map a branch to a local folder and by opening the files there you're "working on that branch".
As Lee points out you can create separate workspaces for each branch, which will isolate the work areas for each. If you're using a Local Workspace, each workspace gets its own "/tf$" folder, the TFVC equivalent of the "/.git" folder.
There's a couple of documents on MSDN that explain this in a little more detail:
Set up TFVC
Create one or more workspaces
Optimize your workspaces
How do I check in
A changeset in TFVC is the equivalent of a commit in Git, it's a logical set of changed files that is committed/pushed as a whole, or not at all. But just as in Git, you can commit all the changes to your local work area at once, or you can exclude certain changes from the first commit and stick those in a second.
In TFVC you'd normally try to commit a logical set of files that fixed the bug, achieved some goal etc. Though it's still possible to check-out/check-in files individually, chances are much higher that you'll actually cause the sources in the main repository to be in an inconsistent state that way.
See
What is a Changeset
Check in your work
Shelving your work
As for your second question
Depending on how far you'd want to go, you could setup Team Build to actually build the application and to take the configuration from a specific location during the build process. That way you wouldn't have to store the configuration for your production environment with the development settings. Configuration files can contain sensitive information, you might not want to have them in Source Control, except for the development versions.
You can also store the config files in a special folder in each branch and make sure that each time you merge them, they're updated accordingly.
And you can, as Lee mentions, look into Config Transaformations. which apply some XSLT to your config file in the build process. That way you can have multiple config files stored in each branch and the selection of your "Configuration" in Visual Studio will define what the final config looks like.
See:
Tricks with app.config files and click once
The _PublishedApplication Nuget package
SlowCheetah
In terms of use I'm not really sure how to swap between the branches for coding / making changes?
I recommend creating separate workspaces for each branch. This way you won't accidentally check in release code when you are trying to check in dev code. Also, when you want to switch which branch of code you are working on, you switch your workspace. This should keep things "cleaner" and easier to work with.
Do I just open the solution file for the branch I want to work on then save all changes as I go, then commit that as a changeset? Or is it a matter of manually checking the file out, working on it, then checking it back in again?
You shouldn't have to manually check it out. If I remember correctly, it will default to auto check out when you start to make changes. You can check code in however big of chunks as you want. But make sure if you are checking in changes to ClassA.cs that reference needed changes in ClassB.cs, you check that in as well. You don't want to leave the source code in a broken state for the other developers.
If you start working on something and have to suspend that work to do some other task that rose in importance, shelve your work instead of letting your workspace get cluttered up with half done work that makes it difficult to manage check ins.
Given it's a ClickOnce app; each branch is deployed to a different IIS site, meaning diff app identies, paths and settings. Am I right in using branches for this or is there a better way?
I'd look into using web.config transformations for this. You'll still want multiple branches but to separate tested/completed/developing code from each other.
My problem is how to know what files or folder are changed before do commit. I can add all the new files in my working copy before do commit, and the repository changes, but if for example i delete one file of the working copy i dont know the way to add this change before do commit. When you use the tortoise for example before do commit the program shows all the changes of the working copy and you can choose what changes commit and what changes dont. There is some way to do this usin sharp svn?? thanks for your answer!!!
svn status
will tell you the state of the working copy compared to where it was before your last update/commit, if you want to delete something in svn use svn delete