Welcome Guest.   Make a donation to an author on the site September 19, 2014, 06:53:41 AM  *

Please login or register.
Or did you miss your validation email?


Login with username and password (forgot your password?)
Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.


You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.
 
Your Support Funds this Site: View the Supporter Yearbook.
   
   Forum Home   Thread Marks Chat! Downloads Search Login Register  
Pages: [1] 2 3 4 5 6 7 Next   Go Down
  Reply  |  New Topic  |  Print  
Author Topic: DVCS ? (All about Git, Mercurial-Hg and the like...)  (Read 35531 times)
Armando
Charter Member
***
Posts: 2,674



see users location on a map View Profile Give some DonationCredits to this forum member
« on: February 19, 2011, 02:39:16 PM »

DVCS : what system to you use... And why ? I'm also generally curious about the context in which you use it (e.g. : working alone or in a team ? purely for code  ?)...

===

Some background info ?

There's been several discussions about version control systems here, but only a few about DVCS and its open systems (Git, Mercurial...). I admit I installed Tortoise SVN a while ago and never used it. Instead I rely on a few different tools like AutoVer, time stamped backups, notes, etc.

I'm currently working on a coding project (my first "real" one in fact), and am wondering if I should be more rigorous about version control etc. But since I have perfectionist tendencies and tend to loose time on details and unnecessary stuff, I want to avoid getting into something that might be very interesting (no doubt...) BUT that will slow me down for months without giving me any concrete benefits. So... if you have any advice concerning that matter... Thanks. smiley
« Last Edit: September 12, 2011, 11:52:35 AM by Armando » Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."
Glenn Gould
Ath
Supporting Member
**
Posts: 2,212



see users location on a map View Profile WWW Give some DonationCredits to this forum member
« Reply #1 on: February 19, 2011, 02:59:16 PM »

... But since I have perfectionist tendencies...
With that said: Do get some kind of VCS!

If working alone or in a small local team (in the same office): Get SVN, it's easy to set up (locally) and very well documented.
If working in a geographically 'wide area' or a large group of people, get GIT or Mercurial and a hosted central server, or create a project at SourceForge with SVN if somebody really wants that to be used.
Logged

Armando
Charter Member
***
Posts: 2,674



see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #2 on: February 20, 2011, 04:18:33 PM »

Thanks for taking the time to answer. I was thinking of getting acquainted with Tortoise SVN (as I said, it's already installed on my computer, etc.). But then I read comments (mainly from f0dder) about GIT, Mercurial and the like... and how annoying SVN could become in some contexts.

Since all these version control systems seem to take a fair number of hours to get truly familiar with their mechanism and features, I just want to make sure I don't uselessly invest time in a one of them to discover I should've invested energy in "the another one".

So... From what you say ("If working alone or in a small local team (in the same office)"), I should just start working with I've got installed : tortoise SVN. Does that mean that GIT or Mercurial aren't good for these contexts (or not worth the effort) ?
Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."
Glenn Gould
mwb1100
Supporting Member
**
Posts: 1,309


View Profile Give some DonationCredits to this forum member
« Reply #3 on: February 20, 2011, 04:32:59 PM »

I mainly use SVN right now.  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.  TortoiseHg seems to be as featured as TortoiseSVN (and I think that this is a testament to the TortoiseSVN project, since I think that TortoiseHg used that as a starting point).  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.

I think that for most projects (even with a DVCS), you'll still likely have a central 'repository of record' (where your official builds will work from), but I think the especially in a single user or very small team environment, not needing a central server can be really nice.

If you're going to be working on Linux kernel stuff, Git is the obvious choice.

All that said, SVN is still a fine choice, and if you're going to be working with a team that's already familiar with it, I'd lean in that direction.
Logged
f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #4 on: February 20, 2011, 05:39:12 PM »

OK, there's several things to address here.

First things first: 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.

Next, move to either Mercurial or Git right away, go right past Subversion and don't collect the... oh wait, this isn't monopoly. But do avoid svn even if you aren't going to use the distributed features of Hg or Git. Why? If nothing else, speed. A list:

  • 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?
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Tortoise is available for Mercurial as well as Git, even if not entirely as polished as TortoiseSvn. Git is probably the system that feels least polished at the moment, but it's entirely usable.

I'm not sure which one to recommend, though. Git does have all the geekboypowerhead features, and you can definitely blast off your legs with the command line tool...  But if you stick with basic features, it's really not that bad. Both Hg and Git can be used for pretty much the same workflow as you have with Subversion, so IMHO there's not much use to stick with svn unless you have to for interop reasons.

You should probably start by checking out Mercurial and TortoiseHg. Chances are you won't need to look at any of the other projects after that. 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 smiley
Logged

- carpe noctem
Armando
Charter Member
***
Posts: 2,674



see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #5 on: February 20, 2011, 06:55:23 PM »

This is very good info and I appreciate it tremendously. Thanks to you 3 for your generosity.  Kiss

With that said: Do get some kind of VCS!
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.

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.  


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?

* 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.
   

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.
   
* 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.


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.

* 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.


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

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.
« Last Edit: February 20, 2011, 06:58:41 PM by Armando » Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."
Glenn Gould
Armando
Charter Member
***
Posts: 2,674



see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #6 on: February 20, 2011, 11:24:10 PM »

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...smiley :

Quote
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.
Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."
Glenn Gould
Armando
Charter Member
***
Posts: 2,674



see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #7 on: March 02, 2011, 10:06:01 AM »

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.  smiley 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.
Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."
Glenn Gould
Ath
Supporting Member
**
Posts: 2,212



see users location on a map View Profile WWW Give some DonationCredits to this forum member
« Reply #8 on: March 02, 2011, 10:16:02 AM »

Committing changes is a voluntary action and, knowing myself, I'll obviously forget to commit important changes from time to time.  smiley Or am I missing something ?
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.
Logged

f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #9 on: March 02, 2011, 10:53:50 AM »

Committing changes is a voluntary action and, knowing myself, I'll obviously forget to commit important changes from time to time.  smiley Or am I missing something ?
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 smiley
Logged

- carpe noctem
mwb1100
Supporting Member
**
Posts: 1,309


View Profile Give some DonationCredits to this forum member
« Reply #10 on: March 02, 2011, 11:10:00 AM »

Committing changes is a voluntary action and, knowing myself, I'll obviously forget to commit important changes from time to time.  smiley Or am I missing something ?

One thing that git was able to do (but I'm not sure if Mercurial supports this or not) is collapsing a set of changes at the 'tip' of a branch into a single change.  Git also lets you drop changes that are at the tip (though it's pretty easy to get them back if you do it by accident, since the change isn't really gone, it's just not at the tip anymore).  What these features enable is that you can commit your local changes at will, without too much regard for whether or not they're 'correct'. Until you push the changes, they aren't seen by anyone else, and when you have something you want to push publicly, you can squash (that's the term git uses) the several changes into a single, coherent change, and push that to the public repository.
Logged
f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #11 on: March 02, 2011, 11:18:31 AM »

mwb1100: I believe Mercurial has (limited) supported for that stuff as well - Git goes all the way and lets you shoot off your legs by allowing heavy history modification... the kind that's nifty to have, but will make people want to rip out your guts if you ever perform it on world-pushed history smiley
Logged

- carpe noctem
Armando
Charter Member
***
Posts: 2,674



see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #12 on: March 02, 2011, 11:33:40 AM »

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.


Yes, the icon overlay is a nice addition. I'll see if that's enough. I could also just put all my code in Dropbox. Currently I use the free autover.

As far as the IDE is concerned, I'm now working on a VB project. The defunctish VB6, to be precise.

So there's "nothing" for that, AFAIK. Well... there's VSS 6 but... After reading Visual SourceSafe: Microsoft's Source Destruction System and Visual SourceSafe Version Control: Unsafe at any Speed?, I chickened out (old articles, but relevant to the available VSS version...).

For Java projects I'll use Eclipse and, yes, I saw plug-ins/add-ons... But I haven't looked closely as this is not what I'm currently working with.

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 smiley

You are absolutely right : committing isn't about saving random set of changes. What I hypothetically had in mind was a separate branch for automated versioning (which could of course be merged with the "manual" branch... Not that it would have to, but could) -- e.g. each version of that branch would correspond to a "save". However, it's a non-existent solution and I can see why this would not be such a great idea (in terms of clarity, mostly). Using the available solution (i.e. : a separate software to do the arbitrary "versioning" part) seems like the best solution anyway.


One thing that git was able to do (but I'm not sure if Mercurial supports this or not) is collapsing a set of changes at the 'tip' of a branch into a single change.  Git also lets you drop changes that are at the tip (though it's pretty easy to get them back if you do it by accident, since the change isn't really gone, it's just not at the tip anymore).  What these features enable is that you can commit your local changes at will, without too much regard for whether or not they're 'correct'. Until you push the changes, they aren't seen by anyone else, and when you have something you want to push publicly, you can squash (that's the term git uses) the several changes into a single, coherent change, and push that to the public repository.

Thanks for the heads up ! I just looked and there's a mercurial extension that does exactly the same thing : CollapseExtension. And there's a lengthier solution (no extension) described there : Concatenating multiple changesets into one . Alternatively, there's also this : Rebase Project .

The collapse extension sounds useful :

Usage Patterns

This extension is particularly useful when you follow the practice of committing regularly to your local repository, possibly before you've got anything sufficiently complete to be put in a shared repository. Rather than filling the changelog with changes of the "OK it almost works now" type, you can collapse all of your intermediate commits before pushing to the shared repository.

N.B. 'hg collapse' is destructive; it rewrites history. Therefore you should never collapse any changeset that has been pushed to another repository, unless you really know what you are doing.

I'll keep digging... But I'll also eventually have to start coding.  Grin
Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."
Glenn Gould
Renegade
Charter Member
***
Posts: 11,368



Tell me something you don't know...

see users location on a map View Profile WWW Give some DonationCredits to this forum member
« Reply #13 on: March 02, 2011, 08:52:30 PM »

Which integrates best with Visual Studio?
Logged

Slow Down Music - Where I commit thought crimes...

Freedom is the right to be wrong, not the right to do wrong. - John Diefenbaker
Armando
Charter Member
***
Posts: 2,674



see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #14 on: March 02, 2011, 10:15:10 PM »

You can look around, but from what I read in the last few days, it seems that VisualHG which sits on top of TortoiseHg would be the way to go. So you basically install TortoiseHg (usually bundled with the latest stable Mercurial), and then you install VisualHG.

A few links... but there are many others.
http://www.eworldui.net/b...in-for-Visual-Studio.aspx
http://kiln.stackexchange...-visualhg-vs-hgsccpackage
Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."
Glenn Gould
Armando
Charter Member
***
Posts: 2,674



see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #15 on: March 03, 2011, 01:45:14 PM »

In relation to what f0dder said...

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 smiley

"Auto-committing" isn't the way to go... But an option/feature in Tortoise to just popup a reminder after n file modifications in a specific timeframe would definitely be useful, especially since it can't integrate with all IDE (or whatever) out there.

Wouldn't that be a sound feature request ? Would you use it ?
Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."
Glenn Gould
Ath
Supporting Member
**
Posts: 2,212



see users location on a map View Profile WWW Give some DonationCredits to this forum member
« Reply #16 on: March 03, 2011, 02:01:03 PM »

Wouldn't that be a sound feature request ? Would you use it ?
Nope, some language/tools/developers using vcs controlled source induce so many changes, that can be relatively unimportant, but need to be checked in at one moment, while in another environment, a single line changed can make a world of difference that needs to be committed at once. So change-counting doesn't count tongue
Logged

Armando
Charter Member
***
Posts: 2,674



see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #17 on: March 03, 2011, 08:18:51 PM »

Nope, some language/tools/developers using vcs controlled source induce so many changes, that can be relatively unimportant, but need to be checked in at one moment, while in another environment, a single line changed can make a world of difference that needs to be committed at once. So change-counting doesn't count tongue

Sure, in a way change-counting doesn't... count. But in my relative and very imperfect world, it does.

And why couldn't one adjust the parameters depending on the project ? (A simple backup comparison: some backups need to be real time or performed every few min, but others can be performed monthly.)

I understand perfectly well why one would never want to commit randomly. However, I'd vastly prefer to be slightly annoyed by a pop-up from time to time, than potentially loose several hours of work, or simply find myself committing a huge chunk of code that should've been split in smaller part... because I forgot to commit my work.  smiley

Of course I could then rely on autover, AJC or File Hamster. But... Far from ideal.

---

On another note : I wish I could rely on the icon overlay... But they are slightly unreliable here. They change only on F5, and sometimes they don't. I have to open/close the repo/folder for them to update.
Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."
Glenn Gould
Ath
Supporting Member
**
Posts: 2,212



see users location on a map View Profile WWW Give some DonationCredits to this forum member
« Reply #18 on: March 04, 2011, 01:31:43 AM »

They change only on F5, and sometimes they don't. I have to open/close the repo/folder for them to update.
That's related to 2 things: Settings in the TortoiseXX tooling (Check out 'Icon overlays'), and the sometimes flaky icon-cache of Windows (including Win7)
Logged

Armando
Charter Member
***
Posts: 2,674



see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #19 on: March 04, 2011, 09:42:36 AM »

Thanks.
I read a few things about overlays,  but nothing seemed to really apply. I turned ON the "Local Disks Only" setting and see if it helps. (Explorer extension settings --> icons)
Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."
Glenn Gould
Armando
Charter Member
***
Posts: 2,674



see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #20 on: March 04, 2011, 03:19:00 PM »

Hmmmm. I probably shouldn't but I'm currently looking at Git. Who's working with Git here ? Are there reasons why you chose it over Mercurial or Bazaar ?

(Moving a function from one file to another and Git can tell you the history of that single function across the move... ? Really ? Sounds appealing. I guess this is where content tracking (instead of file tracking) shines.)
Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."
Glenn Gould
f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #21 on: March 04, 2011, 03:28:10 PM »

I've settled on Git for moving fSekrit forwards, but that's mainly because of Git's "blow off your legs" power with regards to history rewriting - I want to make the codebase public, but retain no memory in the public codebase from the non-public versions. Yet, at the same time, I want the private repository to have FULL history, and do that without committing future versions to both public and private repositories. Git supports that (even if I haven't worked out the details of how to set it up 100% smiley).

History of a single function that moves? Interesting. That's not something inherent in how git stores the version history, though, unless I've missed something - Git stores the full version of each file for each commit, whereas both subversion and Mercurial store changesets (iirc Mercurial also stores a full-version "every once in a while" so moving between versions doesn't become too slow). But IOW, if Git can do it, it's gotta be history analyzing magic smartness that could potentially be done by everybody else too?

From what I've seen from various comparisons, Git and Mercurial offer most of the same features, as long as you don't need the über-wicked geek functionality (Mercurial pretty much won't let you blow your legs off). Also seems like there's not massive speed differences for "normal" size projects.

Git seems a bit more down and dirty, and the tortoise version still isn't as polished as the tortoise versions of other version control systems... it still shows a bit that Git was originally a whole bunch of shell scripts, instead of designing it "properly" as a C/C++ library with a "proper" front-end smiley
Logged

- carpe noctem
Ath
Supporting Member
**
Posts: 2,212



see users location on a map View Profile WWW Give some DonationCredits to this forum member
« Reply #22 on: March 04, 2011, 03:30:42 PM »

I probably shouldn't but I'm currently looking at Git.
Oh yes, you should, if you have the time, resources and interest in it.
Making a more educated choice now (early/pre-start) is way better than to change half way through your project, if you then discover a feature in the other solution you absolutely must have, for whatever reason.
Logged

housetier
Charter Honorary Member
***
Posts: 1,321


see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #23 on: March 04, 2011, 04:12:18 PM »

I use git with great success, but it does have drawbacks, namely poor support for Windows platform.

It is very fast even with large repositories.

AFAIK mercurial has much wider platform support than git, but is also rather slow. This is from hearsay though.

I chose git at that time because it was the new shit.
Logged
Shades
Member
**
Posts: 1,654


see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #24 on: March 04, 2011, 04:50:04 PM »

The 'portable Git preview' software (for Windows) you can get from softpedia looks to be very promising.


And together with SmartGit (free for personal use) it starts to look quite nice as well.

One hell of lot better than WinCVS at least  Wink

**EDIT
Added the SmartGit part.
« Last Edit: March 04, 2011, 04:57:19 PM by Shades » Logged
Pages: [1] 2 3 4 5 6 7 Next   Go Up
  Reply  |  New Topic  |  Print  
 
Jump to:  
   Forum Home   Thread Marks Chat! Downloads Search Login Register  

DonationCoder.com | About Us
DonationCoder.com Forum | Powered by SMF
[ Page time: 0.065s | Server load: 0.08 ]