>> I prefer Brett's solution. It's one command instead of one command >> per VCS. It works with other version control systems and provides me >> the opportunity to save a copy I can restore later.

Georg> It assumes you already have the copy.

Sure, but the way to get the input to the patch command is easy, and is probably almost the same for any version control system:

whatever-vcs diff > patch.diff

The odds that someone will remember the syntax for the diff command for the VCS are much higher than the revert command. My guess is "diff" is executed more often than any other version control commands except "update" and "commit", and far more often than "revert". Personally, I'm not sure I've ever used "revert" more than a handful of times in my entire professional lifetime.

I realize the world is passing me by and that I'm rapidly turning into a dinosaur w.r.t. distributed version control, but as you write/update the developer's guide remember that proficiency in Python does not necessarily equate to proficiency in version control systems, especially with the less frequently used commands. I personally would prefer that more general commands and concepts be used where possible so that newcomers not be put off unnecessarily by the complexity of version control.

Skip

Nick> Usually, this is because I will have edited the source tree since Nick> applying the patch. Reversion has the advantage of not getting Nick> confused by any additional changes. I also usually use "svn diff" Nick> to save a copy before I revert in case I change my mind.

I routinely use CVS and Subversion at work, occasionally SCCS (yes, we still have a little of that other dinosaur laying about - our sysadmins, what can I say? they are luddites). Most of my interaction with these tools is mediated through the Emacs vc package, so my direct use of the command line is reduced even from what you might think normal. It's generally only when I need to operate on a group of files that I revert to using the command line. That tends to be to check in a group of files or discard one or changes before checking in, generally by taking a diff and unapplying it with with patch, perhaps first saving it to a file. If I want to revert a change after checking it in, I can just pipe the confirmation email through patch.

S

skip@pobox.com wrote:

I realize the world is passing me by and that I'm rapidly turning into a dinosaur w.r.t. distributed version control, but as you write/update the developer's guide remember that proficiency in Python does not necessarily equate to proficiency in version control systems, especially with the less frequently used commands. I personally would prefer that more general commands and concepts be used where possible so that newcomers not be put off unnecessarily by the complexity of version control.

What he said, only bolded and underlined.

Antoine Pitrou wrote:

On Thu, 20 Jan 2011 01:23:26 +1100 Steven D'Aprano steve@pearwood.info wrote:

...

skip@pobox.com wrote:

...

I realize the world is passing me by and that I'm rapidly turning into a dinosaur w.r.t. distributed version control, but as you write/update the developer's guide remember that proficiency in Python does not necessarily equate to proficiency in version control systems, especially with the less frequently used commands. I personally would prefer that more general commands and concepts be used where possible so that newcomers not be put off unnecessarily by the complexity of version control.

What he said, only bolded and underlined.

I'm not sure what the issue is. Is there something, concretely, that needs to be fixed?

You'll have to ask Skip if he thinks there's a concrete problem. I haven't seen one, but I've only been reading this thread with one eye and it may be I've missed the mother of all problems.

The (non-concrete) issue, as I understand it, is simple: be aware that not all Python developers are necessarily expert in DVCSes, and please keep it simple.

>> What he said, only bolded and underlined.

Antoine> I'm not sure what the issue is. Is there something, concretely, Antoine> that needs to be fixed?

Strictly speaking, nothing needs to be "fixed" because nothing is broken. Rephrasing my earlier messages:

1. Being a sophisticated Python programmer (and thus being a potential core developer) does not necessarily equate to being a sophisticated user of (especially distributed) version control systems. I have been programming in Python for about 15 years and have made contributions to the core off-and-on for about 10 years. I have never, not even once, been tempted to learn about or use svnmerge. Even considering the more mundane subcommands of the normal svn and hg commands (not to mention cvs, bzr, git, darcs, etc) there are plenty of different ways to structure the workflow, not all of which will make sense for each of those vcs's, nor will they all make sense to all potential users.

2. There is more than one way to skin many of the cats involved in version control. My preference to use "vcs diff | patch -p0 -R" or "patch -p0 -R < some-email" in preference to "vcs revert <some flags>" is just one example. I'm sure I will be able to master "svn revert" and "hg revert" if necessary, but that knowledge won't transfer at all to CVS (no revert command) and won't transfer 100% to other vcs's because their revert commands will have semantic differences or use different command line flags to dictate the specifics of the action to perform.

3. Not everyone will use the command line (strange as that may seem coming from a decades-long Unix user). Many Windows users (and probably some Mac users) will have GUIs like TortoiseHg. Smart/lazy/ memory-challenged Emacs and vim users will have version control commands built into their editors precisely to paper over the arcane differences which exist between vcs's even for common operations.

Skip

Antoine> Ok, thank you but... are you suggesting something or not?

Yes. Keep the vcs command recommendations simple. At least mention idioms which likely to apply across a wider range of version control systems.

S

On Wed, 19 Jan 2011 19:20:01 +0100 Michael Foord fuzzyman@voidspace.org.uk wrote:

On 19/01/2011 19:10, skip@pobox.com wrote:

...

 Antoine>  Ok, thank you but... are you suggesting something or not?

Yes. Keep the vcs command recommendations simple. At least mention idioms which likely to apply across a wider range of version control systems.

The revert works with svn, hg and bzr. Using patch is not going to work on Windoze unless cygwin has been installed.

You don't need cygwin, just something much smaller with "GNU" in its name: http://gnuwin32.sourceforge.net/packages/patch.htm

(yes, the suggestion is already in the dev guide)

2011/1/19 Michael Foord fuzzyman@voidspace.org.uk:

On 19/01/2011 19:10, skip@pobox.com wrote:

...

Antoine>  Ok, thank you but... are you suggesting something or not?

Yes.  Keep the vcs command recommendations simple.  At least mention idioms which likely to apply across a wider range of version control systems.

The revert works with svn, hg and bzr. Using patch is not going to work on Windoze unless cygwin has been installed.

I thought you were supposed to use some variant of "update" on hg instead revert, though.

On Wed, Jan 19, 2011 at 10:10, skip@pobox.com wrote:

Antoine> Ok, thank you but... are you suggesting something or not?

Yes.  Keep the vcs command recommendations simple.  At least mention idioms which likely to apply across a wider range of version control systems.

I was hoping this would flame out, but two days of discussion suggests otherwise.

I am of the opinion of always listing how to use the CVS to its fullest. It is the thing you will have to interact with the most when doing work on Python, so trying to avoid it is not doing anyone any favours.

That being said, I am not opposed to someone (other than me as I am not going to bother) **adding** a not about `patch -R`, but it should not replace the `svn revert` explanation.

Steven D'Aprano steve@pearwood.info wrote:

skip@pobox.com wrote:

...

I realize the world is passing me by and that I'm rapidly turning into a dinosaur w.r.t. distributed version control, but as you write/update the developer's guide remember that proficiency in Python does not necessarily equate to proficiency in version control systems, especially with the less frequently used commands. I personally would prefer that more general commands and concepts be used where possible so that newcomers not be put off unnecessarily by the complexity of version control.

What he said, only bolded and underlined.

Indeed. I now have to deal with an unholy mix of CVS, Subversion, git, and Mercurial -- a twisty maze of little one-letter options, all so similar, all too powerful. At least with CVS and Subversion you could concentrate your mistakes on a single file :-).

Bill