0

We decided to switch the source control of our .NET project from SourceSafe to Mercurial.

Now the question is that if there any possibility to know what file from the solution is "extracted"(checked out) and if yes, by whom?

serhio
  • 28,010
  • 62
  • 221
  • 374
  • 2
    Do you mean "checked out" as in, having a copy of the file locally; or "checked out" as in, the user has started editing the file ? – driis Jan 23 '13 at 19:49
  • Can you elaborate what you mean by "checked out"? Checked out for writing by someone in their workspace? – Timo Geusch Jan 23 '13 at 19:49
  • "checked out" that means that an user ***modified*** the file. – serhio Jan 23 '13 at 19:51
  • 1
    DVCS doesn't have this brittle and antiqued concept that is strickly a centralized VCS paradigm. Learn to use a good 3 way merge tool like [Beyond Compare 3](http://www.scootersoftware.com/) and get over the fear of actually having to read someone elses code and merge something. –  Jan 23 '13 at 20:02
  • 1
    so this is what I do by posting this question. I learn. – serhio Jan 23 '13 at 20:03
  • Switching source control without training people in the basic concepts is a sure-fire way of creating hell on earth. People try to use the new system the same way they used the old, get into trouble, get angry, blame the tool and whoever made the switch gets shouted at. DVCS (like Mercurial and Git) are very different to CVCS (SourceSafe, CVS, SVN, etc). Educate everyone in the differences before it goes off the rails. – Paul S Jan 29 '13 at 13:27

5 Answers5

4

"Checking out" used to indicate that nobody else should modify that file. This is more generally known as locking, but it is no longer the basis for how a VCS system works; modern systems can merge changes line-by-line, and provide interactive help in the rare cases where changes conflict. (I was skeptical when I first heard about it, but really it works very well).

In Mercurial, each user has their own clone of the repository. I assume your organization also has set up a "central" repository that everyone synchronizes with. Sitting at your workstation, use hg incoming to find out whether someone else has pushed changes to the central server that you do not have yet. But you will only see changes that have been "pushed" to the central repository. In mercurial, users can check in changes to their local clone multiple times, and they remain private until they're "pushed" to the central repo. So you can't ask who is planning to modify a certain file, only who has already submitted modifications.

(Caveat: This leaves out a lot of details. Study the mercurial book to learn how the system works, and how to use it to best advantage).

That said, mercurial does have file locking; it is provided by the LockExtension. You can configure certain types of files to require locking; other users can see if a file is locked, and are prevented from pushing changes to it (unless they "steal" your lock, which they're allowed to do since you might lock a file and go on vacation).

Finally: In the comments you mention some kind of file that should never be worked on by more than one person. In mercurial terms, this is a file for which changes should never be merged. This is most often the case with image files and other so-called "binary" formats. The mercurial way to deal with them is not by locking, but by preventing tools from incoherently "merging" two binary modifications. You'd do this by setting your [merge-patterns] configuration to treat your special files as "binary"; see this question to get the general idea.

In short: You can have locks if you really want them, but there are far better ways to manage your team's collaboration. Learn to take advantage of them and you might not need locks at all.

Community
  • 1
  • 1
alexis
  • 48,685
  • 16
  • 101
  • 161
3

Files are not "checked out" as such in mercurial, rather, mercurial tracks the files in its staging area (locally). If you run hg status from the terminal. It will show you the currently modified files that it is tracking as well as any files that it doesn't know about.

So, when you commit, it will commit the tracked files that have been modified. To add untracked files to the staging area, you can add all untracked files with hg add .

You don't need to worry about checking a file out, mercurial knows what you've changed.

As you are using Visual Studio, you could install a plugin (something like this) which would integrate Mercurial with the IDE and display different icons in the solution explorer for modified files

Robbie
  • 18,750
  • 4
  • 41
  • 45
  • yes, but we have some people that worries that after a modification the file will not be "mergeable". So, if the file is "cheked out" that people does not modify that file at all... and viceversa, if the file is "free", changes can be made. – serhio Jan 23 '13 at 19:57
  • 1
    merging shouldn't be feared when using mercurial, generally it will do the right thing for you and only require interaction from you when there is a conflict. Resolving conflicts is just something you have to do when you work in teams using (any) source control system. There is however far more support built into mercurial for resolving those conflicts, than you might be used to from SourceSafe. Give it a try. – Robbie Jan 23 '13 at 20:06
  • imagine you have a translation file in the TranslationId-Text, and the TranslationId is an incremental number. So this kind of file should never be "checked out" by more than a person. – serhio Jan 24 '13 at 08:29
1

No, Mercurial is decentralized source control. There is no way to reliably know what others might have checked out.

Perhaps you could build something with hooks, but I'd recommend against it. You probably will end up having trouble maintaining such a solution, and it would be brittle because hooks can be disabled locally.

driis
  • 161,458
  • 45
  • 265
  • 341
1

No, Mercurial doesn't have "Lock/Unlock" model totally, only Branch/Merge. Merging isn't problem totally, it may have only some downsides if binary artifacts have to be merged during process (and storing such type of objects in SCM is anti-pattern anyway).

For DVCS situation with locking is even worse, than in CVCS - because every workspace have own copy of repository, independent from others, it's just impossible to check and detect state of some file in all clones.

If changeable binary objects in repository are a must for your workflow and you can't avoid it, you can think about two (different) things:

  • Find, add, use special diff/merge tool for your binaries (Mercurial allow to have separate differ-merger for different file-extensions - see at using docdiff "from a box" for some fyle-types)
  • Select another SCM, in which locking model still present (I can recall only Subversion on the fly)
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • I don't speak about lock-unlock, but just information about current file editors. It may be that I should warn that editors of major changes in the file in order that the work on that file by other people be useless or something like this. – serhio Jan 24 '13 at 08:22
  • imagine you have a translation file in the `TranslationId-Text`, and the TranslationId is an incremental number. So this kind of file should never be "checked out" by more than a person. – serhio Jan 24 '13 at 08:28
  • @serhio - I can't imagine such ugly workflow and style, sorry. This naming convention drive me nuts. For me it's just 'Text', where all time-and-history attributes is a VCS duty – Lazy Badger Jan 24 '13 at 08:36
0

The Mercurial LockExtension conceptually offers what you are looking for but I am not sure it is ready for prime time. I have not been able to get it to function with a central repository.

Mark
  • 452
  • 2
  • 9