I'm forced to use Visual Source Safe 2005 at work. I'd like to combine that with a DVCS, so that I can check in files locally without disrupting my co-workers if there's a bug or it doesn't compile.
In my attempts with Mercurial, it works, but causes a few weird issues. Namely, it thinks someone else has checked out the files I have checked out.
Here's my thoughts on how I should manage it:
Disable auto-checkout.
Work locally in Mercurial
When I'm ready to push my changes...
Clone my Mercurial repository.
Update my Visual Source Safe repository
Pull and merge the two repositories using Mercurial.
Check everything into Visual Source Safe.
Does this sound reasonable? I'm always hearing bad things about VSS, is this just asking for me to see those problems firsthand?
WBlasko
I've found the same problem. I wanted to change files and merge them when needed instead of waiting for some other developer to unlock it. The solution that worked for me was:
1) Get the latest version of a VSS project (I placed all VSS projects under vss):
c:\vss\projectA
2A) Initialize with Mercurial
cd vss\projectA
C:\vss\projectA>hg init
2B) Clone the project to the place where it could be changed at will
hg clone vss\projectA myProjects\projectA
3) Grab the latest changes from the VSS copy (skip if you came from 1 and 2)
C:\myProjects\projectA>hg pull
C:\myProjects\projectA>hg update
(solve conflicts if any)
4) Work at will with the cloned version. Later, push your work to the vss copy:
C:\myProjects\projectA>hg push
(don't run hg update yet, wait for VSS latestes version)
5) Now, perform a checkout of all files to the VSS project
6) Run "hg update" on the VSS project to merge your changes to the latest VSS changes.
C:\vss\projectA>hg update
(if there are conflicts, resolve them)
7) Commit the changes
C:\vss\projectA>hg commit
8) Perform a VSS checkin (releasing the locks to the other folks)
Go back to step 3. repeat steps 3-8 forever then... ;-)
This way you can work with a good version control system while still being able "talk" to legacy projects. You will be also be able to enjoy:
a) No problem with locked files
b) you can share your repository with others that know how to use Hg
c) make branches , etc
Just be carefull to first update/solve conflicts, test and then perform VSS checkin
Cheers,
Luis
Related
I would like to know how is it supposed to do the following in mercurial.
My repository is on our server where mercurial-server is running. I develop on Windows and because my project is supposed to be multiplatform, I've set up Jenkins build server which builds using a Linux slave machine automatically after each push.
Now what I need:
Quite often the build on Linux does not work, because I'm using "treat warnings as errors" and gcc gives different warnings than MSVC. Then I need to fix the build and I don't want to mess the repository with "fixing" commits (often more commits are needed to fix all gcc warnings). It would be ok for me to have a single commit in the repo for a fix of the linux build.
I thought I could just clone the repository to a 'fixing repo' (like a branch using clone) and do as many fixing commits as needed. Then just merge all these commits to the main repo as a single fixing commit. But then I need to make my 'fixing repo' public (i.e. clone the fixing repo to the remote server) to allow jenkins to build the sources. But how to get rid of the 'fixing repo' when the fix is finished? It is probably not a good idea to allow users delete remote repositories, is it?
Possibilities I see:
1) forgot about branching using clone, do a named branch, fix, merge to master branch and close the fixing branch - probably not a common solution in mercurial to create a named branch for this
2) just create a new head (possibly set a bookmark), fix, merge to master head (branch) and close the fixing head (can I close a head?) - better but I still have to do with all fixing commits in the main repository
3) using the cloned 'fixing repo', set up ssh access or even mercurial-server for Jenkins to my personal machine and let it clone from it, build and when the build is fixed, just merge all commit from local 'fixing repo' to remote repository as a single commit
Some better solution? Or do I want to do something unusual?
Thanks.
I need to control the version of a few files accessible via an SMB share. These files will be modified by several people. The files themselves are directly used by a web server.
Since these are production files I wanted to force the users to pull a local copy, edit them, commit and push them back. Unfortunately there is no Mercurial server on that machine.
What would be the appropriate way to configure Mercurial on my side so that:
the versioning (.hg directory) is kept on the share
and that the files on the share are at the latest version?
I do not have access to this server (other than via the share). If I could have a mercurial server on that machine I would have used a hook to update the files in the production directory (I am saying this just to highlight what I want to achieve - this approach is not possible as I do not control that server)
Thanks!
UPDATE: I ended up using an intermediate server (which I have control over). A hook on changegroup triggers a script which i) hg update to have fresh local files ii) copies them to the SMB share
EDIT 1 Following discussions in comments with alex I have looked at the verbose version of the command line output. The \\srv\hg\test1 repo has a [hooks] section with changegroup = hg update. The output from a hg push -v gives some insights:
pushing to \\srv\hg\test1
query 1; heads
(...)
updating the branch cache
running hook changegroup: hg update
'\\srv\hg\test1'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
abort: no repository found in 'C:\Windows' (.hg not found)!
warning: changegroup hook exited with status 255
checking for updated bookmarks
listing keys for "bookmarks"
If I understand correctly the output above:
a cmd.exe was triggered on the client, even though the [hook] was on the receiving server
it tried to update the remote repo
... but failed because UNC are not supported
So alex's answer was correct - it just does not work (yet?) on MS Windows. (Alex please correct me in the comments if I am wrong)
If I understood correctly, you are looking for two things:
A repository hook that will automatically update the production repo to the latest version whenever someone pushes to it. This is simple: You're looking for the answer to this question.
If you can rely on your co-workers to always go through the pull-commit-push process, you're done. If that's not the case, you need a way to prevent people from modifying the production files in place and never committing them.
Unfortunately, I don't think you can selectively withhold write permissions to the checked-out files (but not to the repo) on an SMB share. But you could discourage direct modification by making the location of the files less obvious. Perhaps you could direct people to a second repository, configured so that everything pushed to it is immediately pushed on to the production repository. This repo need not have a checked-out version of the files at all (create it with hg clone -U, or do an hg update -r 0 afterwards), eliminating the temptation to bypass mercurial.
What prevents you from mount your Samba share and run hg init there? You don't need mercurial server (hg serve or more sophisticated things) to perform push/pull operations.
A noob question... i think
I use Mercurial for my project on my laptop. How do i submit the project to an online server like codeplex?
I'm using tortoisehg and i cant find the upload interface for submit the project online...
From the command line, the command is:
hg push <url>
to push changes a remote repository.
In TortoiseHg, this is accessed through the "Synchronize" function, which seems to show up if you right-click in a Windows Explorer window but not on any file. It's also available in the workbench; the icon is 2 arrows pointing in a circle.
For these things, I find the best way to go is to use the command line interface - TortoiseHG is OK if you need to perform some common operations from the file browser, and it's a nice tool to visualize some aspects of your repository, but it doesn't implement all of mercurial's features in full detail, and it renames and bundles some operations for no apparent reason.
I don't know how things work at codeplex, but I assume it is similar to bitbucket or github, in which case here's what you'd do:
Create an empty repository on the remote end (codeplex / bitbucket / ...).
Find the remote repository's URL - for bitbucket, it is https://bitbucket.org/yourname/project, or ssh://hg#bitbucket.org/yourname/project.
From your local repository, commit all pending changes, then issue the command: hg push {remote_url}, where {remote_url} is the URL of the remote repository. This will push all committed changes from your local repository to the remote repository.
Since the remote's head revision (an empty project) is the same as the first revision in your local copy (because all hg repositories start out empty), mercurial should consider the two repositories related and accept the push.
For an introductory guide to command-line mercurial, I recommend http://hginit.com/
I have a large codebase that I have been working on for a while. It is not ready to push live, even experimentally. However, my client is requiring a minor change that I cannot fix without pushing my whole new update (which is not ready). I would like to do the following:
Take a stable changeset (I know which one) and create a codebase that I can then work from in Visual Studio.
Make the (very minor) update
Commit my change
Upload my change to the server
Merge/push my changes
Be able to go on working on my current project with that minor change included
I don't want to screw anything up though. Can anyone offer some advice on how to do this?
Thanks
Sure.
hg clone then hg update <rev> to the stable changeset
Edit the code as needed
hg commit
Upload this version (stable + patch) to the server
hg push to the server (your new patch)
At some point, do hg pull in your main development clone when you don't have any uncommitted changes, then do hg rebase to make Mercurial adjust your main development changesets to come after the patch we made above. The history will then be as if the "hotfix" had been done before you started working on your new development.
I’m new to mercurial, about 2 months now. We are using it on a new project and tried to create a new repo, a clone of the trunk, to be used as release “branch”.
We use a central repo, everyone is pulling/pushing to/from it over https using hgwebdir.cgi. Using on server hg 1.5.4 and “clients” various versions, 1.5.2 -> 1.6.3
Everything thing was ok. The clone was good (hg verify after clone), the only problem is that very soon this repo got corrupted (empty or missing ; in manifests not found).
The main repo is ok, only this release get broken very soon.
The names of the repos are (folder names and published names, all reside in the same root folder):
A.B – for the trunk
A.B.Release – for the release repo
(read something in the docs, which sounded like this might be a issue – see
One other very strange thing is that checkins made only to trunk (A.B) are seen as available on the release branch, and they are displayed as errors on verify ( in manifests not found). Don’t understand how these got there.
Any clues?
It's not an answer, but I'll state that what you're doing is definitely supposed to work. Making sure the wire-protocol has full backwards compatibility is very important to the Mercurial folks.
The "cross-talk" between your two repos is very concerning and shouldn't happen unless someone erroniously used the share extension.
What if you try creating the A.B.Release clone by using clone --pull rather than clone by itself?