[web2py] Re: better mercurial integration
sounds good, thanks for the tip :) On Oct 25, 10:01 am, mdipierro wrote: > This may be useful: > > http://www.ke-cai.net/2010/05/tracking-change-with-google-diff-matchhttp://neil.fraser.name/software/diff_match_patch/svn/trunk/demos/dem... > > look at the page source. It uses: > > http://neil.fraser.name/software/diff_match_patch/svn/trunk/javascrip... > > On Oct 24, 11:15 pm, mart wrote: > > > k, items 1 and 2 should be simple enough item 3, that is a > > different story, but ok, sure. I think merging outside of the > > mercurial context is best though, then simply update the remote > > repository with the merged file (and include good notes describing > > both source files and capturing the diffs of the merge is best). > > > I will be under the gun at work for the next few days, but after that > > will be able to have something for you - by end of week is a good > > buffer. > > > 1 question: how large of added disk space usage would you is > > acceptable - I have an idea that I will look into. (I always favor > > having less network IO, and more disk IO when possible). > > > Let me know if end of week is good for you. > > > Mart > > > On Oct 24, 11:26 pm, mdipierro wrote: > > > > I would be happier with much less... > > > > 1) a button in the /admin/mercurial/revision/ page that says [diff] > > > and provides a text output with a diff between the revision and the > > > current code > > > > 2) a few more fields in the /admin/mercurial/commit page that say > > > > changelog: write something here > > > repository: https://<>.googlecode.com/hg/ > > > push: yes/[no] (if yes code is pushed in googlecode) > > > pop: yes/[no] (if yes, current code is cloned from googlecode and > > > overwritten) > > > > I think of [merge] as a third order approximation and it is difficult > > > to get it right. > > > > Massimo > > > > On Oct 24, 10:16 pm, mart wrote: > > > > > K, good stuff! I'll use what you and Boris came up with and integrate > > > > to mine (will help speed things up) the other project :) and for the > > > > other thing, great idea (i think). what do you mean by "web > > > > repository"? do you mean reproduce from the code behind a live web2py > > > > server instance? which would be a grand idea! if that's what you mean. > > > > I would doable if a well kept manifest (generated through automation > > > > on "pull") describing in xml format file names (path) and rev # be > > > > installed long with web2py. then a simple xmlrpc meg over https should > > > > get you a nice xml file wich can be used to resolve the variables used > > > > in a hg pull cmd. (at least that's what I'd do to start) - I do > > > > something like that to get build automation to talk to the bug > > > > tracking system (keeps QA happy with reports like "build X contains > > > > THIS list of bug fixes as described in THIS list of changelist > > > > description, which contains THIS list of affected files, which was > > > > checked in by THIS user, and reviewd by etc" > > > > > But, please let me know if I got the requirement all wrong, and I'll > > > > be happy to suggest another approach. > > > > > For the diff requirement: I would definitely start fro the bottom up. > > > > This is what I do currently do with Perforce (logic should be > > > > similar). > > > > > 1) I generate an XML representation of a directory structure (where I > > > > need to be able to specify any folder within my dir structure as the > > > > "root" folder (the starting point), and need to be able to exclude > > > > files and/folders as params to the function call. > > > > > 2) once I have my xml object (I like a well structured Element Tree > > > > for this type of thing), I will simply pass the elements (in a loop) > > > > to a function that will have the know-how to return a correct mapping > > > > between repository and workspace (i think Mercurial calls this the > > > > Working Directory). > > > > > 3) diff the file, capture the diff (if any) store it (keeping the the > > > > return strings in order is important, so I keep each return values as > > > > a dictionary within warm brackets of a collection that respects order > > > > (like a deque()). > > > > > once done and have gone through the the complete fileset, then it just > > > > depends on how fancy we want to be (color, special indentation, format > > > > to 2 pages, etc..._) or the complete returned values can be formatted > > > > and handed to araxis (or something like that)... > > > > > in the .hg word, its a little more convoluted in that I believe > > > > another repository needs to be created and changes pulled from the > > > > from the revision you are interested in (can be any revision or > > > > "latest" but it does need to be specified. Would look something like > > > > this: > > > > > mkdir myTempDir > > > > cd myTempDir > > > > hg init > > > > hg pull myTempDir > > > > hg update -r N > > > > > then do that recursive diff as discussed above > > > > > is this what you were
[web2py] Re: better mercurial integration
This may be useful: http://www.ke-cai.net/2010/05/tracking-change-with-google-diff-match.html http://neil.fraser.name/software/diff_match_patch/svn/trunk/demos/demo_diff.html look at the page source. It uses: http://neil.fraser.name/software/diff_match_patch/svn/trunk/javascript/diff_match_patch.js On Oct 24, 11:15 pm, mart wrote: > k, items 1 and 2 should be simple enough item 3, that is a > different story, but ok, sure. I think merging outside of the > mercurial context is best though, then simply update the remote > repository with the merged file (and include good notes describing > both source files and capturing the diffs of the merge is best). > > I will be under the gun at work for the next few days, but after that > will be able to have something for you - by end of week is a good > buffer. > > 1 question: how large of added disk space usage would you is > acceptable - I have an idea that I will look into. (I always favor > having less network IO, and more disk IO when possible). > > Let me know if end of week is good for you. > > Mart > > On Oct 24, 11:26 pm, mdipierro wrote: > > > I would be happier with much less... > > > 1) a button in the /admin/mercurial/revision/ page that says [diff] > > and provides a text output with a diff between the revision and the > > current code > > > 2) a few more fields in the /admin/mercurial/commit page that say > > > changelog: write something here > > repository: https://<>.googlecode.com/hg/ > > push: yes/[no] (if yes code is pushed in googlecode) > > pop: yes/[no] (if yes, current code is cloned from googlecode and > > overwritten) > > > I think of [merge] as a third order approximation and it is difficult > > to get it right. > > > Massimo > > > On Oct 24, 10:16 pm, mart wrote: > > > > K, good stuff! I'll use what you and Boris came up with and integrate > > > to mine (will help speed things up) the other project :) and for the > > > other thing, great idea (i think). what do you mean by "web > > > repository"? do you mean reproduce from the code behind a live web2py > > > server instance? which would be a grand idea! if that's what you mean. > > > I would doable if a well kept manifest (generated through automation > > > on "pull") describing in xml format file names (path) and rev # be > > > installed long with web2py. then a simple xmlrpc meg over https should > > > get you a nice xml file wich can be used to resolve the variables used > > > in a hg pull cmd. (at least that's what I'd do to start) - I do > > > something like that to get build automation to talk to the bug > > > tracking system (keeps QA happy with reports like "build X contains > > > THIS list of bug fixes as described in THIS list of changelist > > > description, which contains THIS list of affected files, which was > > > checked in by THIS user, and reviewd by etc" > > > > But, please let me know if I got the requirement all wrong, and I'll > > > be happy to suggest another approach. > > > > For the diff requirement: I would definitely start fro the bottom up. > > > This is what I do currently do with Perforce (logic should be > > > similar). > > > > 1) I generate an XML representation of a directory structure (where I > > > need to be able to specify any folder within my dir structure as the > > > "root" folder (the starting point), and need to be able to exclude > > > files and/folders as params to the function call. > > > > 2) once I have my xml object (I like a well structured Element Tree > > > for this type of thing), I will simply pass the elements (in a loop) > > > to a function that will have the know-how to return a correct mapping > > > between repository and workspace (i think Mercurial calls this the > > > Working Directory). > > > > 3) diff the file, capture the diff (if any) store it (keeping the the > > > return strings in order is important, so I keep each return values as > > > a dictionary within warm brackets of a collection that respects order > > > (like a deque()). > > > > once done and have gone through the the complete fileset, then it just > > > depends on how fancy we want to be (color, special indentation, format > > > to 2 pages, etc..._) or the complete returned values can be formatted > > > and handed to araxis (or something like that)... > > > > in the .hg word, its a little more convoluted in that I believe > > > another repository needs to be created and changes pulled from the > > > from the revision you are interested in (can be any revision or > > > "latest" but it does need to be specified. Would look something like > > > this: > > > > mkdir myTempDir > > > cd myTempDir > > > hg init > > > hg pull myTempDir > > > hg update -r N > > > > then do that recursive diff as discussed above > > > > is this what you were looking for? > > > > Mart :) > > > > connect to app admin through script: > > > On Oct 24, 9:14 pm, mdipierro wrote: > > > > > Actually I just did this with some help from Boris from the mercurial > > > > mailing li
[web2py] Re: better mercurial integration
I am flying to a conference so there is no hurry. Anything you can get done within the next 8 days will be great. On Oct 24, 11:15 pm, mart wrote: > k, items 1 and 2 should be simple enough item 3, that is a > different story, but ok, sure. I think merging outside of the > mercurial context is best though, then simply update the remote > repository with the merged file (and include good notes describing > both source files and capturing the diffs of the merge is best). > > I will be under the gun at work for the next few days, but after that > will be able to have something for you - by end of week is a good > buffer. > > 1 question: how large of added disk space usage would you is > acceptable - I have an idea that I will look into. (I always favor > having less network IO, and more disk IO when possible). > > Let me know if end of week is good for you. > > Mart > > On Oct 24, 11:26 pm, mdipierro wrote: > > > I would be happier with much less... > > > 1) a button in the /admin/mercurial/revision/ page that says [diff] > > and provides a text output with a diff between the revision and the > > current code > > > 2) a few more fields in the /admin/mercurial/commit page that say > > > changelog: write something here > > repository: https://<>.googlecode.com/hg/ > > push: yes/[no] (if yes code is pushed in googlecode) > > pop: yes/[no] (if yes, current code is cloned from googlecode and > > overwritten) > > > I think of [merge] as a third order approximation and it is difficult > > to get it right. > > > Massimo > > > On Oct 24, 10:16 pm, mart wrote: > > > > K, good stuff! I'll use what you and Boris came up with and integrate > > > to mine (will help speed things up) the other project :) and for the > > > other thing, great idea (i think). what do you mean by "web > > > repository"? do you mean reproduce from the code behind a live web2py > > > server instance? which would be a grand idea! if that's what you mean. > > > I would doable if a well kept manifest (generated through automation > > > on "pull") describing in xml format file names (path) and rev # be > > > installed long with web2py. then a simple xmlrpc meg over https should > > > get you a nice xml file wich can be used to resolve the variables used > > > in a hg pull cmd. (at least that's what I'd do to start) - I do > > > something like that to get build automation to talk to the bug > > > tracking system (keeps QA happy with reports like "build X contains > > > THIS list of bug fixes as described in THIS list of changelist > > > description, which contains THIS list of affected files, which was > > > checked in by THIS user, and reviewd by etc" > > > > But, please let me know if I got the requirement all wrong, and I'll > > > be happy to suggest another approach. > > > > For the diff requirement: I would definitely start fro the bottom up. > > > This is what I do currently do with Perforce (logic should be > > > similar). > > > > 1) I generate an XML representation of a directory structure (where I > > > need to be able to specify any folder within my dir structure as the > > > "root" folder (the starting point), and need to be able to exclude > > > files and/folders as params to the function call. > > > > 2) once I have my xml object (I like a well structured Element Tree > > > for this type of thing), I will simply pass the elements (in a loop) > > > to a function that will have the know-how to return a correct mapping > > > between repository and workspace (i think Mercurial calls this the > > > Working Directory). > > > > 3) diff the file, capture the diff (if any) store it (keeping the the > > > return strings in order is important, so I keep each return values as > > > a dictionary within warm brackets of a collection that respects order > > > (like a deque()). > > > > once done and have gone through the the complete fileset, then it just > > > depends on how fancy we want to be (color, special indentation, format > > > to 2 pages, etc..._) or the complete returned values can be formatted > > > and handed to araxis (or something like that)... > > > > in the .hg word, its a little more convoluted in that I believe > > > another repository needs to be created and changes pulled from the > > > from the revision you are interested in (can be any revision or > > > "latest" but it does need to be specified. Would look something like > > > this: > > > > mkdir myTempDir > > > cd myTempDir > > > hg init > > > hg pull myTempDir > > > hg update -r N > > > > then do that recursive diff as discussed above > > > > is this what you were looking for? > > > > Mart :) > > > > connect to app admin through script: > > > On Oct 24, 9:14 pm, mdipierro wrote: > > > > > Actually I just did this with some help from Boris from the mercurial > > > > mailing list. > > > > > Now if you run web2py from source ad you have mercurial installed > > > > (easy_install mercurial) you can use the web2py admin to: > > > > > - create a repository (this is don
[web2py] Re: better mercurial integration
k, items 1 and 2 should be simple enough item 3, that is a different story, but ok, sure. I think merging outside of the mercurial context is best though, then simply update the remote repository with the merged file (and include good notes describing both source files and capturing the diffs of the merge is best). I will be under the gun at work for the next few days, but after that will be able to have something for you - by end of week is a good buffer. 1 question: how large of added disk space usage would you is acceptable - I have an idea that I will look into. (I always favor having less network IO, and more disk IO when possible). Let me know if end of week is good for you. Mart On Oct 24, 11:26 pm, mdipierro wrote: > I would be happier with much less... > > 1) a button in the /admin/mercurial/revision/ page that says [diff] > and provides a text output with a diff between the revision and the > current code > > 2) a few more fields in the /admin/mercurial/commit page that say > > changelog: write something here > repository: https://<>.googlecode.com/hg/ > push: yes/[no] (if yes code is pushed in googlecode) > pop: yes/[no] (if yes, current code is cloned from googlecode and > overwritten) > > I think of [merge] as a third order approximation and it is difficult > to get it right. > > Massimo > > On Oct 24, 10:16 pm, mart wrote: > > > K, good stuff! I'll use what you and Boris came up with and integrate > > to mine (will help speed things up) the other project :) and for the > > other thing, great idea (i think). what do you mean by "web > > repository"? do you mean reproduce from the code behind a live web2py > > server instance? which would be a grand idea! if that's what you mean. > > I would doable if a well kept manifest (generated through automation > > on "pull") describing in xml format file names (path) and rev # be > > installed long with web2py. then a simple xmlrpc meg over https should > > get you a nice xml file wich can be used to resolve the variables used > > in a hg pull cmd. (at least that's what I'd do to start) - I do > > something like that to get build automation to talk to the bug > > tracking system (keeps QA happy with reports like "build X contains > > THIS list of bug fixes as described in THIS list of changelist > > description, which contains THIS list of affected files, which was > > checked in by THIS user, and reviewd by etc" > > > But, please let me know if I got the requirement all wrong, and I'll > > be happy to suggest another approach. > > > For the diff requirement: I would definitely start fro the bottom up. > > This is what I do currently do with Perforce (logic should be > > similar). > > > 1) I generate an XML representation of a directory structure (where I > > need to be able to specify any folder within my dir structure as the > > "root" folder (the starting point), and need to be able to exclude > > files and/folders as params to the function call. > > > 2) once I have my xml object (I like a well structured Element Tree > > for this type of thing), I will simply pass the elements (in a loop) > > to a function that will have the know-how to return a correct mapping > > between repository and workspace (i think Mercurial calls this the > > Working Directory). > > > 3) diff the file, capture the diff (if any) store it (keeping the the > > return strings in order is important, so I keep each return values as > > a dictionary within warm brackets of a collection that respects order > > (like a deque()). > > > once done and have gone through the the complete fileset, then it just > > depends on how fancy we want to be (color, special indentation, format > > to 2 pages, etc..._) or the complete returned values can be formatted > > and handed to araxis (or something like that)... > > > in the .hg word, its a little more convoluted in that I believe > > another repository needs to be created and changes pulled from the > > from the revision you are interested in (can be any revision or > > "latest" but it does need to be specified. Would look something like > > this: > > > mkdir myTempDir > > cd myTempDir > > hg init > > hg pull myTempDir > > hg update -r N > > > then do that recursive diff as discussed above > > > is this what you were looking for? > > > Mart :) > > > connect to app admin through script: > > On Oct 24, 9:14 pm, mdipierro wrote: > > > > Actually I just did this with some help from Boris from the mercurial > > > mailing list. > > > > Now if you run web2py from source ad you have mercurial installed > > > (easy_install mercurial) you can use the web2py admin to: > > > > - create a repository (this is done automatically and it also makes > > > a .hgignore) > > > - commit file > > > - see log changes > > > - see list of files for each committed revision > > > - revert to past revision > > > > (all by just clicking) > > > > One important missing feature is the ability to get a diff vs a given > > > revision. > > > Another feat
[web2py] Re: better mercurial integration
I would be happier with much less... 1) a button in the /admin/mercurial/revision/ page that says [diff] and provides a text output with a diff between the revision and the current code 2) a few more fields in the /admin/mercurial/commit page that say changelog: write something here repository: https://<>.googlecode.com/hg/ push: yes/[no] (if yes code is pushed in googlecode) pop: yes/[no] (if yes, current code is cloned from googlecode and overwritten) I think of [merge] as a third order approximation and it is difficult to get it right. Massimo On Oct 24, 10:16 pm, mart wrote: > K, good stuff! I'll use what you and Boris came up with and integrate > to mine (will help speed things up) the other project :) and for the > other thing, great idea (i think). what do you mean by "web > repository"? do you mean reproduce from the code behind a live web2py > server instance? which would be a grand idea! if that's what you mean. > I would doable if a well kept manifest (generated through automation > on "pull") describing in xml format file names (path) and rev # be > installed long with web2py. then a simple xmlrpc meg over https should > get you a nice xml file wich can be used to resolve the variables used > in a hg pull cmd. (at least that's what I'd do to start) - I do > something like that to get build automation to talk to the bug > tracking system (keeps QA happy with reports like "build X contains > THIS list of bug fixes as described in THIS list of changelist > description, which contains THIS list of affected files, which was > checked in by THIS user, and reviewd by etc" > > But, please let me know if I got the requirement all wrong, and I'll > be happy to suggest another approach. > > For the diff requirement: I would definitely start fro the bottom up. > This is what I do currently do with Perforce (logic should be > similar). > > 1) I generate an XML representation of a directory structure (where I > need to be able to specify any folder within my dir structure as the > "root" folder (the starting point), and need to be able to exclude > files and/folders as params to the function call. > > 2) once I have my xml object (I like a well structured Element Tree > for this type of thing), I will simply pass the elements (in a loop) > to a function that will have the know-how to return a correct mapping > between repository and workspace (i think Mercurial calls this the > Working Directory). > > 3) diff the file, capture the diff (if any) store it (keeping the the > return strings in order is important, so I keep each return values as > a dictionary within warm brackets of a collection that respects order > (like a deque()). > > once done and have gone through the the complete fileset, then it just > depends on how fancy we want to be (color, special indentation, format > to 2 pages, etc..._) or the complete returned values can be formatted > and handed to araxis (or something like that)... > > in the .hg word, its a little more convoluted in that I believe > another repository needs to be created and changes pulled from the > from the revision you are interested in (can be any revision or > "latest" but it does need to be specified. Would look something like > this: > > mkdir myTempDir > cd myTempDir > hg init > hg pull myTempDir > hg update -r N > > then do that recursive diff as discussed above > > is this what you were looking for? > > Mart :) > > connect to app admin through script: > On Oct 24, 9:14 pm, mdipierro wrote: > > > > > > > Actually I just did this with some help from Boris from the mercurial > > mailing list. > > > Now if you run web2py from source ad you have mercurial installed > > (easy_install mercurial) you can use the web2py admin to: > > > - create a repository (this is done automatically and it also makes > > a .hgignore) > > - commit file > > - see log changes > > - see list of files for each committed revision > > - revert to past revision > > > (all by just clicking) > > > One important missing feature is the ability to get a diff vs a given > > revision. > > Another feature I would like to have is the ability to push from a web > > repository or revert to it. > > > On Oct 24, 8:09 pm, mart wrote: > > > > Hi Massimo, > > > > Ok, now I feel bad... I have not had the time to finish the > > > integration app I promised... Much is done, but not yet complete... I > > > still do intend on completing though... hopefully soon... > > > > Until then, what is your intent here? are you looking to restore a > > > fileset (or entire tree) to a specific version from repo (without > > > changing meta data), are you looking to drop all meta changes, revert > > > you local code line to known state? > > > > are you looking for a quick and dirty recipe like with combination of > > > cmds to delete local changesets and revert to a speciic version (or > > > #head revision) of the remote depot? like: > > > delete local repo, then: > > > hg init --> create new > > > hg pull --
[web2py] Re: better mercurial integration
K, good stuff! I'll use what you and Boris came up with and integrate
to mine (will help speed things up) the other project :) and for the
other thing, great idea (i think). what do you mean by "web
repository"? do you mean reproduce from the code behind a live web2py
server instance? which would be a grand idea! if that's what you mean.
I would doable if a well kept manifest (generated through automation
on "pull") describing in xml format file names (path) and rev # be
installed long with web2py. then a simple xmlrpc meg over https should
get you a nice xml file wich can be used to resolve the variables used
in a hg pull cmd. (at least that's what I'd do to start) - I do
something like that to get build automation to talk to the bug
tracking system (keeps QA happy with reports like "build X contains
THIS list of bug fixes as described in THIS list of changelist
description, which contains THIS list of affected files, which was
checked in by THIS user, and reviewd by etc"
But, please let me know if I got the requirement all wrong, and I'll
be happy to suggest another approach.
For the diff requirement: I would definitely start fro the bottom up.
This is what I do currently do with Perforce (logic should be
similar).
1) I generate an XML representation of a directory structure (where I
need to be able to specify any folder within my dir structure as the
"root" folder (the starting point), and need to be able to exclude
files and/folders as params to the function call.
2) once I have my xml object (I like a well structured Element Tree
for this type of thing), I will simply pass the elements (in a loop)
to a function that will have the know-how to return a correct mapping
between repository and workspace (i think Mercurial calls this the
Working Directory).
3) diff the file, capture the diff (if any) store it (keeping the the
return strings in order is important, so I keep each return values as
a dictionary within warm brackets of a collection that respects order
(like a deque()).
once done and have gone through the the complete fileset, then it just
depends on how fancy we want to be (color, special indentation, format
to 2 pages, etc..._) or the complete returned values can be formatted
and handed to araxis (or something like that)...
in the .hg word, its a little more convoluted in that I believe
another repository needs to be created and changes pulled from the
from the revision you are interested in (can be any revision or
"latest" but it does need to be specified. Would look something like
this:
mkdir myTempDir
cd myTempDir
hg init
hg pull myTempDir
hg update -r N
then do that recursive diff as discussed above
is this what you were looking for?
Mart :)
connect to app admin through script:
On Oct 24, 9:14 pm, mdipierro wrote:
> Actually I just did this with some help from Boris from the mercurial
> mailing list.
>
> Now if you run web2py from source ad you have mercurial installed
> (easy_install mercurial) you can use the web2py admin to:
>
> - create a repository (this is done automatically and it also makes
> a .hgignore)
> - commit file
> - see log changes
> - see list of files for each committed revision
> - revert to past revision
>
> (all by just clicking)
>
> One important missing feature is the ability to get a diff vs a given
> revision.
> Another feature I would like to have is the ability to push from a web
> repository or revert to it.
>
> On Oct 24, 8:09 pm, mart wrote:
>
> > Hi Massimo,
>
> > Ok, now I feel bad... I have not had the time to finish the
> > integration app I promised... Much is done, but not yet complete... I
> > still do intend on completing though... hopefully soon...
>
> > Until then, what is your intent here? are you looking to restore a
> > fileset (or entire tree) to a specific version from repo (without
> > changing meta data), are you looking to drop all meta changes, revert
> > you local code line to known state?
>
> > are you looking for a quick and dirty recipe like with combination of
> > cmds to delete local changesets and revert to a speciic version (or
> > #head revision) of the remote depot? like:
> > delete local repo, then:
> > hg init --> create new
> > hg pull --> get a version
> > hg update --> well, just update...
>
> > Although, by reading your commit script, I'd say you're pretty handy
> > with mercurial API as it is.
>
> > anyways, depends what you are looking to do... I can give you some
> > quick and dirty recipes if you like, if it helps.
>
> > Mart :)
>
> > On Oct 24, 6:23 pm, Massimo Di Pierro wrote:
>
> > > Hello everybody,
>
> > > I am working on improving the web2py web interface to mercurial.
>
> > >http://127.0.0.1:8000/admin/mercurial/commit
>
> > > We can current create a repo, commit and get changelog but I cannot
> > > figure out how to do revert.
> > > Here is the code I have:
>
> > > import os
> > > uio = ui.ui()
> > > uio.quiet = True
> > > if not os.environ.get('HGUSER') and not uio.config("
[web2py] Re: better mercurial integration
Actually I just did this with some help from Boris from the mercurial
mailing list.
Now if you run web2py from source ad you have mercurial installed
(easy_install mercurial) you can use the web2py admin to:
- create a repository (this is done automatically and it also makes
a .hgignore)
- commit file
- see log changes
- see list of files for each committed revision
- revert to past revision
(all by just clicking)
One important missing feature is the ability to get a diff vs a given
revision.
Another feature I would like to have is the ability to push from a web
repository or revert to it.
On Oct 24, 8:09 pm, mart wrote:
> Hi Massimo,
>
> Ok, now I feel bad... I have not had the time to finish the
> integration app I promised... Much is done, but not yet complete... I
> still do intend on completing though... hopefully soon...
>
> Until then, what is your intent here? are you looking to restore a
> fileset (or entire tree) to a specific version from repo (without
> changing meta data), are you looking to drop all meta changes, revert
> you local code line to known state?
>
> are you looking for a quick and dirty recipe like with combination of
> cmds to delete local changesets and revert to a speciic version (or
> #head revision) of the remote depot? like:
> delete local repo, then:
> hg init --> create new
> hg pull --> get a version
> hg update --> well, just update...
>
> Although, by reading your commit script, I'd say you're pretty handy
> with mercurial API as it is.
>
> anyways, depends what you are looking to do... I can give you some
> quick and dirty recipes if you like, if it helps.
>
> Mart :)
>
> On Oct 24, 6:23 pm, Massimo Di Pierro wrote:
>
> > Hello everybody,
>
> > I am working on improving the web2py web interface to mercurial.
>
> >http://127.0.0.1:8000/admin/mercurial/commit
>
> > We can current create a repo, commit and get changelog but I cannot figure
> > out how to do revert.
> > Here is the code I have:
>
> > import os
> > uio = ui.ui()
> > uio.quiet = True
> > if not os.environ.get('HGUSER') and not uio.config("ui", "username"):
> > os.environ['HGUSER'] = 'web...@localhost'
> > try:
> > repo = hg.repository(ui=uio, path=path)
> > except:
> > repo = hg.repository(ui=uio, path=path, create=True)
>
> > given repo and a revision number from repo.changelog, how to I revert all
> > files to that revision using the API?
>
> > Massimo
>
>
[web2py] Re: better mercurial integration
Hi Massimo,
Ok, now I feel bad... I have not had the time to finish the
integration app I promised... Much is done, but not yet complete... I
still do intend on completing though... hopefully soon...
Until then, what is your intent here? are you looking to restore a
fileset (or entire tree) to a specific version from repo (without
changing meta data), are you looking to drop all meta changes, revert
you local code line to known state?
are you looking for a quick and dirty recipe like with combination of
cmds to delete local changesets and revert to a speciic version (or
#head revision) of the remote depot? like:
delete local repo, then:
hg init --> create new
hg pull --> get a version
hg update --> well, just update...
Although, by reading your commit script, I'd say you're pretty handy
with mercurial API as it is.
anyways, depends what you are looking to do... I can give you some
quick and dirty recipes if you like, if it helps.
Mart :)
On Oct 24, 6:23 pm, Massimo Di Pierro wrote:
> Hello everybody,
>
> I am working on improving the web2py web interface to mercurial.
>
> http://127.0.0.1:8000/admin/mercurial/commit
>
> We can current create a repo, commit and get changelog but I cannot figure
> out how to do revert.
> Here is the code I have:
>
> import os
> uio = ui.ui()
> uio.quiet = True
> if not os.environ.get('HGUSER') and not uio.config("ui", "username"):
> os.environ['HGUSER'] = 'web...@localhost'
> try:
> repo = hg.repository(ui=uio, path=path)
> except:
> repo = hg.repository(ui=uio, path=path, create=True)
>
> given repo and a revision number from repo.changelog, how to I revert all
> files to that revision using the API?
>
> Massimo
