Main Area and Open Discussion > General Software Discussion
DVCS ? (All about Git, Mercurial-Hg and the like...)
Armando:
This is very good info and I appreciate it tremendously. Thanks to you 3 for your generosity. :-*
With that said: Do get some kind of VCS!
-Ath (February 19, 2011, 02:59 PM)
--- End quote ---
get some version control, right now. Even if you're never going to collaborate with other people, you'll learn to appreciate it. VCS serves as part of a backup scheme, it's easier to find particular versions of your source code than dealing with timestamped copies, and once you become disciplined and write proper commit messages and commit at a proper granularity, you'll see you have some powerful tools at hand to search history, track regressions, managed branches et cetera. It does take a bit getting really used to VCS and reap all the benefits, but it's worth investing time in it.
-f0dder (February 20, 2011, 05:39 PM)
--- End quote ---
Yes, I will get it, right now. The idea of building my own versioning system when more powerful, accurate, flexible, etc. systems exist... Felt stupid. My only fear was that it'd overkill. But you guys said what I needed to hear :
If I were starting from nothing, I think I'd consider Mercurial over SVN - it seems less complex than Git and seem a bit more Windows friendly. [...] I'm considering converting my personal SVN repository to Mercurial, and hosting it on https://bitbucket.org/ where you can have free private repositories.
-mwb1100 (February 20, 2011, 04:32 PM)
--- End quote ---
And... I'm going to aim for DVCS and will first try Mercurial + TortoiseHg.
basically, All of the points f0dder brought forward, and a few others, completely convinced me to go this way.
Here are these points...
1- Speed and efficiency :
* Fetching the entire Notepad++ Community Release wia Git via my 20mbit ADSL is faster than grabbing fSekrit with subversion on my gigabit LAN. Nuff' said?
-f0dder (February 20, 2011, 05:39 PM)
--- End quote ---
* Since dvcs store all files locally in addition to the (optional) remote repository, switching branches or datamining history is lightning fast. With subversion, even on a gigabit lan some operations can be painfully slow.
-f0dder (February 20, 2011, 05:39 PM)
--- End quote ---
2- "Cleanliness", robustness, reliability :
* Subversion stores it's info in ".svn" folders in each and every subfolder of your project. This is ugly, it means you have to use "svn export" to grab/export a clean subtree, and if you forget to do this and copy subfolders around in your svn-managed project, you can screw things up majorly. Both Hg and Git use a single top-level folder per project.
-f0dder (February 20, 2011, 05:39 PM)
--- End quote ---
* Even though subversion has metadata scattered in all those .svn folders, you don't have the full project history locally - so if your remote repository goes AWOL, you're screwed. With Hg and Git, your own machine has a full local copy of all history.
-f0dder (February 20, 2011, 05:39 PM)
--- End quote ---
3- Useful flexibility
* Subversion doesn't treat branches and tags specially, but just as part of the filesystem. This does, kinda, give you some flexibility, but it's flex you don't need, and it can cause a lot of clutter and fuss if you aren't very disciplined with how you arrange stuff.
-f0dder (February 20, 2011, 05:39 PM)
--- End quote ---
* Branches in svn always go to your repository, meaning they're slightly slow operations to perform, they "pollute" the namespace, etc. Thus, with svn, you think a lot before you make a branch, especially on a multi-dev project. With Hg and Git, you can do local "feature branches" to work on without disturbing other people, and merge those to the current working branch before pushing your changes upstream. In other words, YOU have a lot of flexibility on your own machine, without necessarily cluttering things for everybody else. Even on single-dev projects, it's nice being able to take a break from adding a new feature to fix a bug, and then merge it all together.
-f0dder (February 20, 2011, 05:39 PM)
--- End quote ---
4- Adaptability, reusability...
And if you stay clear of svn, you won't need to muck around with converting your repositories when you feel like ditching it at some later point
-f0dder (February 20, 2011, 05:39 PM)
--- End quote ---
I'm considering converting my personal SVN repository to Mercurial, and hosting it on https://bitbucket.org/ where you can have free private repositories. If bitbucket ever goes away, that's not a big deal since any workspace I have is essentially a full backup of the repository. Moving my hosted SVN stuff was a bit of a pain when my 1st hoster dropped their free plans.
-mwb1100 (February 20, 2011, 04:32 PM)
--- End quote ---
Armando:
It's a bit long but this part from the Mercurial manual gives interesting info, particularly in relation to this thread. Of course it might be a bit subjective...:) :
1.6.1. Subversion
Subversion is a popular revision control tool, developed to replace CVS. It has a centralised client/server architecture.
Subversion and Mercurial have similarly named commands for performing the same operations, so if you're familiar with one, it is easy to learn to use the other. Both tools are portable to all popular operating systems.
Prior to version 1.5, Subversion had no useful support for merges. At the time of writing, its merge tracking capability is new, and known to be complicated and buggy [http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword].
Mercurial has a substantial performance advantage over Subversion on every revision control operation I have benchmarked. I have measured its advantage as ranging from a factor of two to a factor of six when compared with Subversion 1.4.3's ra_local file store, which is the fastest access method available. In more realistic deployments involving a network-based store, Subversion will be at a substantially larger disadvantage. Because many Subversion commands must talk to the server and Subversion does not have useful replication facilities, server capacity and network bandwidth become bottlenecks for modestly large projects. Additionally, Subversion incurs substantial storage overhead to avoid network transactions for a few common operations, such as finding modified files (status) and displaying modifications against the current revision (diff). As a result, a Subversion working copy is often the same size as, or larger than, a Mercurial repository and working directory, even though the Mercurial repository contains a complete history of the project.
Subversion is widely supported by third party tools. Mercurial currently lags considerably in this area. This gap is closing, however, and indeed some of Mercurial's GUI tools now outshine their Subversion equivalents. Like Mercurial, Subversion has an excellent user manual.
Because Subversion doesn't store revision history on the client, it is well suited to managing projects that deal with lots of large, opaque binary files. If you check in fifty revisions to an incompressible 10MB file, Subversion's client-side space usage stays constant The space used by any distributed SCM will grow rapidly in proportion to the number of revisions, because the differences between each revision are large.
In addition, it's often difficult or, more usually, impossible to merge different versions of a binary file. Subversion's ability to let a user lock a file, so that they temporarily have the exclusive right to commit changes to it, can be a significant advantage to a project where binary files are widely used.
Mercurial can import revision history from a Subversion repository. It can also export revision history to a Subversion repository. This makes it easy to “test the waters” and use Mercurial and Subversion in parallel before deciding to switch. History conversion is incremental, so you can perform an initial conversion, then small additional conversions afterwards to bring in new changes.
1.6.2. Git
Git is a distributed revision control tool that was developed for managing the Linux kernel source tree. Like Mercurial, its early design was somewhat influenced by Monotone.
Git has a very large command set, with version 1.5.0 providing 139 individual commands. It has something of a reputation for being difficult to learn. Compared to Git, Mercurial has a strong focus on simplicity.
In terms of performance, Git is extremely fast. In several cases, it is faster than Mercurial, at least on Linux, while Mercurial performs better on other operations. However, on Windows, the performance and general level of support that Git provides is, at the time of writing, far behind that of Mercurial.
While a Mercurial repository needs no maintenance, a Git repository requires frequent manual “repacks” of its metadata. Without these, performance degrades, while space usage grows rapidly. A server that contains many Git repositories that are not rigorously and frequently repacked will become heavily disk-bound during backups, and there have been instances of daily backups taking far longer than 24 hours as a result. A freshly packed Git repository is slightly smaller than a Mercurial repository, but an unpacked repository is several orders of magnitude larger.
The core of Git is written in C. Many Git commands are implemented as shell or Perl scripts, and the quality of these scripts varies widely. I have encountered several instances where scripts charged along blindly in the presence of errors that should have been fatal.
Mercurial can import revision history from a Git repository.
--- End quote ---
Armando:
So, I got into Mercurial and like it. I also subscribed to a bitbucket account, etc. It definitely seems fast, unintrusive and powerful (some little "side effect features" like the propagation of changes across file copies is quite nice).
Some early "2¢ thoughts":
While the documentation is generally superb, I found that the support concerning the actual organization of repositories not that clear (e.g. : can I create sub-repositories inside a main repository ? should I have one general repository containing all sub-projets ? or should I create a repository for each sub-project and nothing for the encompassing project folder, etc.?). Anyway : I just created a repository for each (sub) project since I didn't find any simple way to manage repositories hierarchies with TortoiseHg. (Speaking of TortoiseHg, I first started learning Mercurial by reading the... Mercurial manual. And I must say that the command line feels more simple than the Tortoise GUI. But who knows... I might change my mind.)
I can also see some "room" for other automatic versioning/backup solutions like AJC backup, autover or File Hamster (in addition to Mercurial). Committing changes is a voluntary action and, knowing myself, I'll obviously forget to commit important changes from time to time. :) Or am I missing something ?
That's it for now... Thanks for helping me with my choice. Seems like Mercurial was what I was looking for.
Ath:
Committing changes is a voluntary action and, knowing myself, I'll obviously forget to commit important changes from time to time. :) Or am I missing something ?
-Armando (March 02, 2011, 10:06 AM)
--- End quote ---
That's probably the main reason the icon overlays in Windows Explorer turn red if something has changed locally. You have to take action yourself though, no auto-commit (nor would I want that).
You haven't mentioned the programming environment/IDE you are using for your project. Maybe that has an integration, as most of the big IDE's have it (NetBeans, Eclipse and descendants, Visual Studio). Some of them can even warn you if you try to close without committing your changes.
f0dder:
Committing changes is a voluntary action and, knowing myself, I'll obviously forget to commit important changes from time to time. :) Or am I missing something ?-Armando (March 02, 2011, 10:06 AM)
--- End quote ---
First, there's no way to really tell when a file modification is done and complete - the best heuristic you could go by is "file has been modified, and now hasn't been additionally modified for n seconds".
Second, you don't want commits based on random modifications - at least when programming, you'll often be doing a related set of changes across a few files, and then commit that. Think of it as not commiting files, but committing features :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version