Deprecating fetch

[Laurens Holst]

Op 02-09-11 01:11, Jesse Glick schreef:
> (In fact I would appreciate a command to not just fetch but then 
> immediately push the result so long as there were no 3-way file 
> merges. Sure there _might_ be some semantic problem resulting from the 
> merge, but this is quite rare in a big repo, and anyway that is what 
> continuous integration is for. Compared to CVS/Subversion users, for 
> whom commit does an implicit merge

Afaik in SVN that isn’t true... if one of the files you’re committing 
has been changed it will tell you to update first (aka pull + 
update/merge), just like Mercurial. But since SVN basically does 
file-by-file versioning whereas Mercurial does repository-wide 
versioning, SVN does allow you to commit files if they did not change in 
the repository.

In fact, Mercurial’s update has kind of similar semantics; it will only 
tell you to merge if one of your changed files has also changed in the 
repository. So hg pull -u && hg commit -m "..." && hg push is similar to 
what svn commit -m "..." does. With the advantage that if the update 
fails, it doesn’t litter your repo with partially changed files and 
conflict markers. You could make a simple shell script for that I 
suppose, no need for an extension.

Then again, I find the fact that pushing is a separate step one of 
Mercurial’s strengths. Pushing separately allows you to commit easily 
and frequently without rigorous testing, and you only push once you’ve 
got a group of working and tested changes. This way you won’t as often 
block other developers because you committed something broken, which is 
a very common problem with SVN. Also once you’ve pushed you can’t use 
rollback anymore, and that’s something I use all the time ;p.

Anyway, I guess this is getting off-topic :).

~Laurens