I'm learning the mercurial source code management system and doing the examples using hgsharp.
In that I studied the hg clone ,
done in command prompt as per the tutorial instruction (see the above screenshot), but can't understand how the files are creating while cloning process is in progress. I tried using hgsharp as they coded in the HgCloneTest, but only the .hg folder is created, other files are not created.
Could somebody say me how the files are created while cloning a repo.
Well, at last I understood the concept. While cloning a particular repo if we say --no update, then the working directory will not get updated. Thanks to #Kindread.
Also, That HgSharp is cloning the repo by not updating the working directory and does not cover 100% functionality.
Related
Is there any way to move classes from one source code file to a new one without losing version control history? We are using TFS.
Thanks.
It's based on which version control system you are working with:
This not possible with TFVC as Marvin Glenn Lacuna also described very clearly above, However you could try the following workaroud:
Branch FileX to FileA
Branch FileX to FileB
Open each file and delete the party you don't want
Delete FileX
Now you could maintain history on all of the visible lines of pre code
through the branch relationship.
For GIT, you could take a look at this question: How does git track source code moved between files?
In TFS, from my experience, the simple answer is no, it stays on the source file and will remain in the source file. It will not be copied to the target file (ctrl+c, ctrl+v). I believe that's why it is called "file history" and not file section/classes history.
With current TFS version, the default version control is Git.
So you could do it by a trick.
Assume that you have two classes ClassA and ClassB in a file named File.ext, your source code is at branch master.
The steps should be:
Create branch 'developA' from 'master'
Call 'git mv File.ext ClsA.ext' then commit to have ClsA.ext with history of File.ext
Cleanup ClassB in ClsA.ext then commit.
Create branch 'developB' from 'master'
Call 'git mv File.ext ClsB.ext' then commit to have ClsB.ext with history of File.ext
Cleanup ClassA in ClsB.ext then commit.
Merge two branches 'developA' and 'developB' then push to 'master'
Now you have both files ClsA.ext and ClsB.ext without losing their history from File.ext.
An example could be found at my github repository.
This is the situation I have:
I created an installer. It has python scripts, executable, and other file types. In the installer, I run a C# executable as a custom action, after registering the product. The C# executable moves the files into different locations (i.e. a text document will be moved to My Documents). I understand I can do this without the custom actions, but I was not aware of that when I created the installer.
Now, after I have distributed the software, users are running into small bugs. For instance, there is a bad if check in one of the python scripts.
Question Is there a way to fix the portion of the python script/executable/text document that is broken, and simply update those files (without having to redistribute the software to the users, and having them reinstall it)?
A patch probably won't help you. If the locations are fixed within the install, a minor upgrade could do the trick, if you make all the files that need to stay the same "never overwrite" (unless the custom action ignores this, then things might get difficult).
If the locations are determined during the execution of the custom action, or the locations are based on user input during the install, then you have a problem if you haven't saved the location paths (in the registry, for example). I don't think you want a custom action to scan all the drives of the computer just to find the files.
If the files are put in their new locations by the custom action, windows installer probably won't see them as key files and probably won't "repair" them in any scenario. If the fixes are few, you might be better of distributing the files separately with a clear instruction, in stead of spending many hours on a difficult new custom action.
Cheers, B.
I'm sorry, apparently I missed the trigger that you had placed a comment.
If this is this something you would like to know, look at this table. It shows when to use major, minor or small fix (patch).
Hope it helps.
Cheers!
http://helpnet.installshield.com/installshield17helplib/MajorMinorSmall.htm
I keep having a situation where gets annoying (with TFS). I searched for "TFS" and "Recursive folder/files" but didn't find something similar in SOF and then good it but not exactly what I need.
I have checked out a project from TFS (#1) on my local machine and then after some modifications did update them on a new TFS (#2). Later noticed on TFS #2 have:
Solution folder
folder 1/folder 2/files
folder 2
folder 3/folder 3/files
I checked back on TFS #1 things were OK however, for a reason when it gets to my local drive it can get recursive. Anybody knows what I have done wrong? or any settings are involved?
One thing is that folders which go recursive are other developers projects.
Thank you!
I am using the most recent version of anksvn for a visual studio 2008 project file. I now
want to check this code into anksvn, but I am having a problem.
The situtation is, I checked in the most current version of code into anksvn. That is fine.
However I have another version of this code that I did not check out from subversion initially. This other copy of the code was for a 'demo' only. However now this code needs to become the production code. Thus I am trying to determine how to check this code into anksvn.
What I know I can do is to 'remove' the most curent code folder that is in anksvn. I could then place this project folder into that location. since the origianl 'demo' code also includes the current production code.
However I am trying to see if there is a better method to accomplish this goal. Could I possibly use the branch/switch option?
Is the demo code checked out of Subversion at all? I know you didn't check it out, but was it checked out? If it was, you could commit this code back into Subversion, then update your working directory.
It his code has nothing to do with Subversion, you will have to take a more complex route: You will have to copy the changes manually to your code.
Since you're using Windows, you should take a look at Beyond Compare, This is commercial code, but you can download a limited time demo for free -- more than enough time to handle your situation. I use Beyond Compare all the time to compare two different directories or Java jar files or zip archives, etc. It not only can quickly show you the differences, but makes it each to copy those differences from one to the other.
I have no relationship with Scooter software, the makers of Beyond Compare except as a customer.
So I've created a simple msi-setup for my application using a setup project and added a couple of custom actions that take care of stuff like extracting files from archives. Now, there are two extra files in my program files -directory which means that the MSI won't remove the directory at the uninstall by itself. My solution to this was to create a custom action that removes the rest of the files.
Now this works just fine and dandy, as long as the default directory is used at installation. But what if the user chooses to change it? I'd assume there has to be a very simple way to read the directory at the custom action, but I'm not quite sure what that is.
As far as I've found out by googling, there are properties such as TARGETDIR related to the MSI-package. However, some sites also say that I should be setting this property by myself, at the installation stage.
All this has left me quite confused. Basically I see two ways to resolve this:
1) Make sure the application does not create files by itself, and the MSI will take care of it. This would mean a bit more work because I'm not responsible for those extra files.
2) Find out the installation directory at the custom action while uninstalling the application, and remove the last bits by myself. This is the quick-and-dirty way as I see it, and would definitely suffice for now. But how to accomplish this?
Also while I'm here I might as well ask this one more related question. As I mentioned earlier, I extract some files at the install. Now, I'd like to get rid of these archives once I've extracted them. The problem is, if I do this, MSI will think my installation is broken and copy them back each time I launch the application. So how to avoid this?
There is no need to use a custom action to remove the files. MSI has built in support for this scenario in two steps:
Use a search to locate the files you want to remove. Here is a tutorial
http://msdn.microsoft.com/en-us/library/aa371564(VS.85).aspx
Then you can schedule a file removal operation to actually delete the files.
http://msdn.microsoft.com/en-us/library/aa371201(VS.85).aspx
Regarding your second question:
Don't add the archives to the File table. Instead create some self extracting archives and use binary custom actions to unpack them.
http://msdn.microsoft.com/en-us/library/aa368085(VS.85).aspx