Mecurial source control
Daniel Hommel
during the last few evenings i started to hack on a new and hopefully
improved version of a Mercurial source control for CC.NET.
As far as i understand the issues some users have reported this version
should fix them. Additionally i ported some of the features of the Git
source control.
I still have to fix the tests or (write new ones) and add documentation,
but i want to release the Mercurial.cs (see attachment) now so you can
review it and suggest changes / give comments / express wishes.
Ported from the Git source control:
- commit build modifications
- commit untracked and deleted files
- clean working copy (hg purge)
Still missing:
- How to update subrepos?
Stuff i'm still undecided about:
- clone or init&pull?
- option 1: clone in GetModifications()
- option 2: init in GetModifications() and pull in GetSource()
- use hg incoming instead of hg log to get the modifications?
- commit build modifications first then tag, or the other way around?
So please let me know what you think about it and what you would change
or improve. Finally i thank Kent Johnson for the initial version and
Daniel Nauck for the (very clean) Git code that inspired me to do
this...
Best regards,
Daniel
Bill Barry
functionality (http://jira.public.thoughtworks.org/browse/CCNET-1188),
but I guess you could be meaning the Git code...
init+pull is still better than clone because it can support the
additional use case of having ccnet directly use the repository you push
to instead of having ccnet pull from a different location; for this
reason as well, hg log was used instead of hg incoming [1]
I still don't like the way I had grouped all files together (in the
history template I used "<files>{files}</files>" for that part but this
results in all the files being grouped together in one string in the
modification class and a fairly ugly output on the page when dozens of
files are modified in the same changeset; when I put that there [several
releases of hg ago] there was not any better way to do it, but this
should be revisited if there might be a better way to try that again).
Also I am not seeing any code to do this here, but I think ccnet should
actually take the time to enable the purge extension if it is going to
use it (by adding it to the hgrc file for the repo). Aside from that
this all looks pretty good. init+pull here also makes it slightly
simpler to write this file as clone would have written the default
location into the hgrc while init wouldn't.
1: I had thought that some people may want to set the hg repository up
that they were going to use CI for as the repository for the CI server.
They would do something like this:
> hg clone https://ccnet.mycompany.com/hg/master .\working
... do work
> hg ci -m "some work done"
> hg push
After this the changes would already be in the repository that the ccnet
server is using; the server, having kept track of the last version which
it built from (which was always `hg parent` from the working copy) could
get the logs up to the version it was planning to build (when I wrote
it, this was `hg tip`). This was also the only way that tagging worked
too because tags were not pushed out to a remote repo. If you have
solved the tagging issue then I guess the rest of this isn't really a
concern (but should be tested still to make sure that anyone who was
using it this way can either continue to do so or can migrate to a
preferred configuration with little hassle). Doing this would reduce
network traffic because the ccnet server wouldn't need to ever pull
(which is why the configuration property Repository in the source is not
required).
Daniel Hommel
On Mon, 2010-12-20 at 16:24 -0700, Bill Barry wrote:
> I am pretty sure I wrote the initial version of the Mercurial
> functionality (http://jira.public.thoughtworks.org/browse/CCNET-1188),
> but I guess you could be meaning the Git code...
Oh you're right! I remember merging it, but Kent Johnson was listed in
the xml docs of the Mercurial.cs file as external contributor... Well, i
will add you to the docs as soon as i commit any changes...
> init+pull is still better than clone because it can support the
> additional use case of having ccnet directly use the repository you push
> to instead of having ccnet pull from a different location; for this
> reason as well, hg log was used instead of hg incoming [1]
Good point. I didn't think about pushing directly to the repo the server
uses. Somehow i always let the server have its own working copy, even
with DVCS. I'll try that out and see where it leads me. It would be nice
if both options would work.
> I still don't like the way I had grouped all files together (in the
> history template I used "<files>{files}</files>" for that part but this
> results in all the files being grouped together in one string in the
> modification class and a fairly ugly output on the page when dozens of
> files are modified in the same changeset; when I put that there [several
> releases of hg ago] there was not any better way to do it, but this
> should be revisited if there might be a better way to try that again).
Also a good point i completely missed. I'll see what current hg versions
offer.
> Also I am not seeing any code to do this here, but I think ccnet should
> actually take the time to enable the purge extension if it is going to
> use it (by adding it to the hgrc file for the repo).
I was already planning to implement a method that configures the
repository after creating it, but i'm still uncertain about how to do
it. The most elegant way would be to patch the hgrc file with an ini
reader/writer, but that might also be overkill. Maybe i'll just create
the hgrc file and overwrite it if needed. Git has a config command for
that, but sadly hg doesn't.
> Aside from that
> this all looks pretty good. init+pull here also makes it slightly
> simpler to write this file as clone would have written the default
> location into the hgrc while init wouldn't.
>
> 1: I had thought that some people may want to set the hg repository up
> that they were going to use CI for as the repository for the CI server.
> They would do something like this:
> > hg clone https://ccnet.mycompany.com/hg/master .\working
> ... do work
> > hg ci -m "some work done"
> > hg push
>
> After this the changes would already be in the repository that the ccnet
> server is using; the server, having kept track of the last version which
> it built from (which was always `hg parent` from the working copy) could
> get the logs up to the version it was planning to build (when I wrote
> it, this was `hg tip`). This was also the only way that tagging worked
> too because tags were not pushed out to a remote repo. If you have
> solved the tagging issue then I guess the rest of this isn't really a
> concern (but should be tested still to make sure that anyone who was
> using it this way can either continue to do so or can migrate to a
> preferred configuration with little hassle). Doing this would reduce
> network traffic because the ccnet server wouldn't need to ever pull
> (which is why the configuration property Repository in the source is not
> required).
Ah that's why your version used hg parents. I actually wondered why it
is needed at all. From the tests i've done so far tagging works as
expected. The tags also get pushed to remote repo, but i might also be
missing something here. Going to do more testing...
Thanks for your comments!
Best regards,
Daniel
Daniel Hommel
a second reply...
On Mon, 2010-12-20 at 16:24 -0700, Bill Barry wrote:
> I still don't like the way I had grouped all files together (in the
> history template I used "<files>{files}</files>" for that part but this
> results in all the files being grouped together in one string in the
> modification class and a fairly ugly output on the page when dozens of
> files are modified in the same changeset; when I put that there [several
> releases of hg ago] there was not any better way to do it, but this
> should be revisited if there might be a better way to try that again).
I just found something in the hgbook [1] that solves this problem.
Put something like the following in a file (let's assume it's called
ccnet_modifications):
changeset = "<modification><node>{node|short}</node><author>{author|
user}</author><date>{date|rfc822date}</date><desc>{desc|
escape}</desc><rev>{rev}</rev><email>{author|email|
obfuscate}</email><files>{files}</files></modification>"
file = "<file>{file}</file>"
Then call something like
hg log --style ccnet_modifications
and it will add a file tag around each file, which should be easy to
parse. We can also add newlines or what else we need. :-)
Best regards,
Daniel
[1]
http://hgbook.red-bean.com/read/customizing-the-output-of-mercurial.html
Bill Barry
> I just found something in the hgbook [1] that solves this problem.
>
> Put something like the following in a file (let's assume it's called
> ccnet_modifications):
>
> changeset = "<modification><node>{node|short}</node><author>{author|
> user}</author><date>{date|rfc822date}</date><desc>{desc|
> escape}</desc><rev>{rev}</rev><email>{author|email|
> obfuscate}</email><files>{files}</files></modification>"
> file = "<file>{file}</file>"
>
> Then call something like
>
> hg log --style ccnet_modifications
>
didn't know how to do the ccnet side of it. Happy to hear that there is
a way.
I'll be glad to help out however I can on all of this but I don't really
have any time to code anything in the relative future. I should be able
to do some reviewing though if you can keep putting the code out in the
open.
Daniel Hommel
> I should be able to do some reviewing though if you
> can keep putting the code out in the open.
As an experiment i created a mercurial mirror of the subversion
repository on bitbucket:
http://bitbucket.org/dhommel/ccnet-mirror
I'll keep this version clean and try to update it frequently so anyone
with a bitbucket account can easily fork it and create patch queues.
Additionally, i forked my own repo and pushed the code i sent to
ccnet-devel earlier:
http://bitbucket.org/dhommel/ccnet-hgnew
I'll keep pushing updates to this location until everything is in a
shape that can go into the subversion repository (code ready, docs,
tests working)...
Feel free to send me comments. I might also let people push to the
forked repo if anybody wants to help.
Best regards,
Daniel