Main Area and Open Discussion > General Software Discussion

DVCS ? (All about Git, Mercurial-Hg and the like...)

<< < (3/39) > >>

mwb1100:
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 ---

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.

f0dder:
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 :)

Armando:
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.
-Ath (March 02, 2011, 10:16 AM)
--- End quote ---


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 :)
-f0dder (March 02, 2011, 10:53 AM)
--- End quote ---

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.
-mwb1100 (March 02, 2011, 11:10 AM)
--- End quote ---

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. -http://mercurial.selenic.com/wiki/CollapseExtension
--- End quote ---

I'll keep digging... But I'll also eventually have to start coding.  ;D

Renegade:
Which integrates best with Visual Studio?

Armando:
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/blog/post/2010/03/15/VisualHG-A-Mercurial-Plugin-for-Visual-Studio.aspx
http://kiln.stackexchange.com/questions/1103/what-are-the-pros-and-cons-of-visualhg-vs-hgsccpackage

Navigation

[0] Message Index

[#] Next page

[*] Previous page