After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 435511 - Add support for mercurial
Add support for mercurial
Status: RESOLVED FIXED
Product: jhbuild
Classification: Infrastructure
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Jhbuild maintainers
Jhbuild QA
Depends on:
Blocks:
 
 
Reported: 2007-05-03 14:04 UTC by Marco Barisione
Modified: 2007-05-28 19:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
hg backend (3.56 KB, patch)
2007-05-03 14:06 UTC, Marco Barisione
none Details | Review
hg backend (7.86 KB, patch)
2007-05-04 14:37 UTC, Marco Barisione
none Details | Review
hg backend (5.61 KB, patch)
2007-05-04 17:04 UTC, Marco Barisione
none Details | Review
hg backend (8.34 KB, patch)
2007-05-04 17:06 UTC, Marco Barisione
committed Details | Review

Description Marco Barisione 2007-05-03 14:04:21 UTC
I wrote a backend to support the mercurial version control system based on the darcs one.
Comment 1 Marco Barisione 2007-05-03 14:06:57 UTC
Created attachment 87452 [details] [review]
hg backend
Comment 2 Frederic Peters 2007-05-03 14:26:43 UTC
buildscript.execute(['hg', 'pull', '-u'], 'hg', cwd=self.srcdir)

Will 'hg pull' return a non-zero error code on conflicts ?
Comment 3 Marco Barisione 2007-05-04 09:09:33 UTC
"-u" just means to run an update after the pull. If there are unresolved conflicts hg runs something like meld so the user can try to resolve the conflict. You can set the env variable HGMERGE to overwrite the merge program so if you set HGMERGE to /bin/false then "hg update" returns 1 in case of error.

But there is a problem, a second update does not fail:

$ hg pull
pulling from <REPO-NAME>
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)

$ HGMERGE=false hg update; echo "RETURN VALUE: $?"
merging <FILENAME>
merging <FILENAME> failed!
0 files updated, 0 files merged, 0 files removed, 1 files unresolved
There are unresolved merges with locally modified files.
You can redo the full merge using:
  hg update <REVISION-NAME1>
  hg update <REVISION-NAME2>
RETURN VALUE: 1

$ HGMERGE=false hg update; echo "RETURN VALUE: $?"
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
RETURN VALUE: 0


To avoid it you can run "hg update <REVISION-NAME1>" as suggested by the output of the update command. To do it I need to pipe the output of the command but using buildscript.execute() it seems impossible, however I can add a "hg-pull-update" script to do this.

Using this script I could modify the output of hg so conflicts are reported as starting with "C ", this way frontends can treat it as the output of cvs or svn.
Comment 4 Frederic Peters 2007-05-04 09:12:55 UTC
That would be great.
Comment 5 Marco Barisione 2007-05-04 14:37:59 UTC
Created attachment 87529 [details] [review]
hg backend

jhbuild/versioncontrol/hg.py is the mercurial backend.

jhbuild/versioncontrol/hg-update.py is the script used to update a mercurial repo, conflicts are printed prefixed with "C " as done by svn and cvs.

jhbuild/frontends/autobuild.py and jhbuild/frontends/terminal.py have been modified to highlight conflicts when updating mercurial repositories.
Comment 6 Frederic Peters 2007-05-04 14:51:02 UTC
Great, one more little nitpick, hopefully last: could hg-update.py be moved to the scripts/ directory ?

Also, would it be possible to have a get_revision_id method, this will be used to fix bug 313997, whenever time comes.

Thanks.
Comment 7 Marco Barisione 2007-05-04 16:05:33 UTC
The problem is that the scripts directory is not distributed in the Debian package for jhbuild.

What should do get_revision_id? Just return an unique id for the current revision?

Something like this code (not tested!) would be ok?

def get_revision_id(self):
    hg = Popen(['hg', 'ti', '--template', '{node}'], stdout=PIPE)
    return hg.stdout.read().strip()

Comment 8 Frederic Peters 2007-05-04 16:20:42 UTC
I don't know if hg ti --template {node} is correct but your description "return an uniqueid for the current revision" is, so I guess it is fine :)

As for hg-update.py, it can probably be shipped in the Debian package, just have to ask the maintainer.  Hey Loic, are you listening ?
Comment 9 Marco Barisione 2007-05-04 17:04:15 UTC
Created attachment 87547 [details] [review]
hg backend

Added get_revision_id and moved the hg-update.py script to the scripts directory.

I don't like the way I use to get the position of the script:
  hg_update_path = os.path.join(os.path.dirname(__file__), '..',
                                '..', 'scripts', hg_update)
  hg_update_path = os.path.normpath(hg_update_path)
Comment 10 Marco Barisione 2007-05-04 17:06:53 UTC
Created attachment 87549 [details] [review]
hg backend

The previous patch does not contain hg-update.py script.
Comment 11 Loïc Minier 2007-05-04 19:43:22 UTC
(In reply to comment #8)
> As for hg-update.py, it can probably be shipped in the Debian package, just
> have to ask the maintainer.  Hey Loic, are you listening ?

Sure; I've noted it on my TODO, but feel free to request such things via the BTS.
Comment 12 Frederic Peters 2007-05-28 19:07:44 UTC
Sorry I went away before commiting your work; I just did it.  Thanks again.

2007-05-28  Frederic Peters  <fpeters@0d.be>

        * jhbuild/versioncontrol/hg.py, scripts/hg-update.py,
        jhbuild/frontends/autobuild.py, jhbuild/frontends/terminal.py:
        add support for mercurial (patch by Marco Barisione, closes: #435511)