On Tue, May 13, 2014 at 03:24:51PM -0500, Felipe Contreras wrote:
> William Giokas wrote:
> > On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
> > > As you say, it's perfectly OK.
> >
> > But wrong. Yes, it works, but it's not how it should be done when we
> > have a code review such as this. It should simply not be done and makes
> > no sense to do with an 'if <check ver>; else' kind of thing later in the
> > application.
>
> That's exactly how it should be done. Maybe this visualization helps
>
> from mercurial import hg, ui, bookmarks, ... # for hg >= 3.0
> from mercurial import node, error, extensions, ... # for hg >= 3.0
> from mercurial import changegroup # for hg >= 3.0
>
> if check_version(3, 0):
> cg = changegroup.getbundle(repo, 'push', ... # for hg >= 3.0
> else:
> cg = repo.getbundle('push', heads=list(p_revs) # for hg < 3.0
>
> Eventually the code would become:
>
> from mercurial import hg, ui, bookmarks, ... # for hg >= 3.0
> from mercurial import node, error, extensions, ... # for hg >= 3.0
> from mercurial import changegroup # for hg >= 3.0
>
> cg = changegroup.getbundle(repo, 'push', ... # for hg >= 3.0
No, the way that it's going to change is that the import statements will
change, not the 'if:else' things. It would work exactly the same with
this, however the things that are used only in a specific version for
this are stated up front. Maybe this visualization helps for what I have
set up::
from mercurial import ... # for all hg
try:
from mercurial.changegroup import getbundle # for hg with
# changegroup.getbundle,
# regardless of version
except ImportError: # for hg from before the
def getbundle(__empty__, **kwargs): # move to changegroup
return repo.getbundle(**kwargs)
...
cg = getbundle(...)
When we eventually remove support for mercurial that uses
repo.getbundle:
from mercurial import changegroup, ... # for all hg
...
cg = changegroup.getbundle(...)
That should make sense. You could even just remove the try: and except:
bits and just to 'from mercurial.changegroup import getbundle' and not
mess with the meat of the code at all.
> The fact that at some point 'import changegroup' was not needed is
> irrelevant.
>
> Primarily we want to support the current version of Mercurial.
> Secondarily we want to support older versions. That's why we add the
> repo.getbundle() code (as an addendum to the core part).
So I use arch myself, and I am very used to the 'rolling release' model
that it employs. I do agree that we should concentrate support for the
latest release, but for a project like git the other versions of hg
cannot be ignored, as this project is used on so many different systems.
> > > We could try that, but that would assume we want to maintain getbundle()
> > > for the long run, and I personally don't want to do that. I would rather
> > > contact the Mercurial developers about ways in which the push() method
> > > can be improved so we don't need to have our own version. Hopefully
> > > after it's improved we wouldn't have to call getbundle().
> >
> > Assuming that mercurial <3.0 will not change, then this should never
> > need to change.
>
> But it should. Otherwise the code will keep having more and more hacks
> and it will become less and less maintainable.
>
> That's why we don't have code for hg 1.0; because it would require too
> many hacks, and nobody cared anyway.
>
> Just like nobody cares about hg 1.0, eventually nobody will care about
> hg 2.0.
Yes, it can change. Eventually hg 2.0 will be defunct and no one will
use it, but what happens if they go back to the old 2.0 style for
getbundle in hg 4.0? We're already good. What if they switch it back in
4.1? This works for all of those conditions, and doesn't do anything if
we're able to get mercurial.changegroup.getbundle.
> > Changes in 'getbundle' upstream would require changes either way.
>
> I doubt we will see any more changes in getbundle, at least not until
> 4.0, and hopefully by then we wouldn't be using it anyway. I am willing
> to bet we won't see those changes.
>
> > > Moreover, eventually there will be a Mercurial 4.0, even 5.0, and at
> > > some point we would want to remove the hacks for older versions. When we
> > > do so we would want the import to remain unconditionally, and remove the
> > > 'check_version(3, 0)' which is already helping to explain what the code
> > > is for without the need of comments.
> >
> > The same exact thing can be done with this. In fact, it would probably
> > allow us to have better future-proofing with regards to new versions of
> > mercurial, there would just be different try:except statements at the
> > beginning.
>
> No, your code doesn't show that this is for versiosn <= 3.0,
> 'check_version(3, 0)' does.
That's the whole point. This did not change the instant 3.0 was
released.
> Plus, when we remove this code my version makes it straight forward:
>
> - if check_version(3, 0):
> - cg = changegroup.getbundle(repo, 'push', ...
> - else:
> - cg = repo.getbundle('push', heads=list(p_revs), ...
> + cg = changegroup.getbundle(repo, 'push', ...
Because it is not there for things that are <3.0, it is there for
systems that are unable to import mercurial.changegroup.getbundle. There
is no reason to apply a version number to this, except for the fact that
hg happened to change in version 3.0. This lets people that are using hg
versions of hg to work through changes.
>
> Not so with your code:
>
> -
> -try:
> - from mercurial.changegroup import getbundle
> -
> -except ImportError:
> - def getbundle(__empty__, **kwargs):
> - return repo.getbundle(**kwargs)
> +from mercurial import getbundle
>
> import re
> import sys
> @@ -1036,7 +1030,7 @@ def push_unsafe(repo, remote, ...
> if not checkheads(repo, remote, p_revs):
> return None
>
> - cg = getbundle(repo, 'push', heads=list(p_revs), ...
> + cg = changegroup.getbundle(repo, 'push', ...
>
>
Hope that made some sense, at least.
Thanks,
--
William Giokas | KaiSforza | http://kaictl.net/
GnuPG Key: 0x73CD09CF
Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
Attachment:
pgpxoDktds5QI.pgp
Description: PGP signature