Since bitkeeper will become unusable for most of us in 2 weeks, I''m wondering what revision control system Xen will be using by then. I''d like to get familiar with the tools and get a changelog bot written before the switchover ;) -- The Theory of Escalating Commitment: "The cost of continuing mistakes is borne by others, while the cost of admitting mistakes is borne by yourself." -- Joseph Stiglitz, Nobel Laureate in Economics _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 2005-06-14 at 15:09 -0400, Rik van Riel wrote:> Since bitkeeper will become unusable for most of us in 2 > weeks, I''m wondering what revision control system Xen will > be using by then. > > I''d like to get familiar with the tools and get a changelog > bot written before the switchover ;)I''ve been holding off on some xentest changes for the same reason. I''d like to give it the ability to pull snapshots from an SCM as soon as we are using a free one. -- Thanks, Paul Larson plars@linuxtestproject.org http://www.linuxtestproject.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ronald G. Minnich
2005-Jun-14 19:27 UTC
Re: [Xen-devel] bitkeeper gone in 2 weeks - which RCS?
v9fs moved to git and it''s been pretty fine. ron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ronald G. Minnich wrote:> v9fs moved to git and it''s been pretty fine.I''ve been using mercurial to track xen-unstable for a couple of weeks now. It''s not perfect, but it''s promising. Also, now there is: http://www.kernel.org/hg It''s tracking the main git repository on an hourly basis. I didn''t see any responses to: http://marc.theaimsgroup.com/?l=mercurial&m=111757509907918&w=2 -Arun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 2005-06-14 at 12:43 -0700, Arun Sharma wrote:> Ronald G. Minnich wrote: > > v9fs moved to git and it''s been pretty fine. > > I''ve been using mercurial to track xen-unstable for a couple of weeks > now. It''s not perfect, but it''s promising. > > Also, now there is: > > http://www.kernel.org/hgInteresting, I hadn''t seen that one before. I had seen this one though, which seems a little more concise to me: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary -- Thanks, Paul Larson plars@linuxtestproject.org http://www.linuxtestproject.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ronald G. Minnich
2005-Jun-14 19:52 UTC
Re: [Xen-devel] bitkeeper gone in 2 weeks - which RCS?
if I did not use git, I would probably just use SVN. I''ve just been through this mess with linuxbios and ''arch'', and arch has just been painful. there are arguably lots better systems than svn, but svn works. ron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ronald G. Minnich wrote:> if I did not use git, I would probably just use SVN. I''ve just been > through this mess with linuxbios and ''arch'', and arch has just been > painful. > > there are arguably lots better systems than svn, but svn works.svn works when you''re not branching and merging frequently. True, there is a lot of noise in the SCM space these days... -Arun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Paul Larson wrote:> Interesting, I hadn''t seen that one before. I had seen this one though, > which seems a little more concise to me: > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summaryTools are richer in the git space because there are more people looking at it (compare the traffic on git vs hg). hg is attempting to leverage some of these by providing command line compatibility for git (called hgit). http://www.selenic.com/hg/?cmd=file;filenode=113b5f9c6c1f5f428b2e946374230c46e153a248;file=contrib/hgit -Arun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 6/15/05, Arun Sharma <arun.sharma@intel.com> wrote:> Paul Larson wrote: > > > Interesting, I hadn''t seen that one before. I had seen this one though, > > which seems a little more concise to me: > > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary > > Tools are richer in the git space because there are more people looking > at it (compare the traffic on git vs hg). hg is attempting to leverage > some of these by providing command line compatibility for git (called hgit). > > http://www.selenic.com/hg/?cmd=file;filenode=113b5f9c6c1f5f428b2e946374230c46e153a248;file=contrib/hgit >like it or not, it seems there are only 3 reasonable options at the moment: 1. svn (i hate cvs). BK also provides a tool to convert bk repo to cvs repo. 2. git 3. mercurial (while this is promissing and written in python, which many people here can hack it if needed, unfortunately mercurial is the most immatured tool compared to the above two) anyway we must choose one. i vote for svn (do we usually fork the repo? i guess not). mercurial is the second choice to me. regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Rusty Russell
2005-Jun-14 23:50 UTC
Re: [Xen-devel] bitkeeper gone in 2 weeks - which RCS?
On Wed, 2005-06-15 at 08:31 +0900, aq wrote:> On 6/15/05, Arun Sharma <arun.sharma@intel.com> wrote: > > Paul Larson wrote: > > > > > Interesting, I hadn''t seen that one before. I had seen this one though, > > > which seems a little more concise to me: > > > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary > > > > Tools are richer in the git space because there are more people looking > > at it (compare the traffic on git vs hg). hg is attempting to leverage > > some of these by providing command line compatibility for git (called hgit). > > > > http://www.selenic.com/hg/?cmd=file;filenode=113b5f9c6c1f5f428b2e946374230c46e153a248;file=contrib/hgit > > > > like it or not, it seems there are only 3 reasonable options at the moment: > > 1. svn (i hate cvs). BK also provides a tool to convert bk repo to cvs repo. > > 2. git > > 3. mercurial (while this is promissing and written in python, which > many people here can hack it if needed, unfortunately mercurial is the > most immatured tool compared to the above two)I like bzr (in Python too), but it''s simply not ready either. Being halfway around the world, I prefer a distributed system over svn. I really dislike the idea of losing the history, but it shouldn''t be too hard to import the existing history (using libsp) into whatever format is chosen. Haven''t played with git, but it seems to have traction. Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Michael Paesold
2005-Jun-15 07:09 UTC
Re: [Xen-devel] bitkeeper gone in 2 weeks - which RCS?
Rusty Russell wrote:> On Wed, 2005-06-15 at 08:31 +0900, aq wrote: >> like it or not, it seems there are only 3 reasonable options at the >> moment: >> >> 1. svn (i hate cvs). BK also provides a tool to convert bk repo to >> cvs repo. >> >> 2. git >> >> 3. mercurial (while this is promissing and written in python, which >> many people here can hack it if needed, unfortunately mercurial is >> the >> most immatured tool compared to the above two) > > I like bzr (in Python too), but it''s simply not ready either. Being > halfway around the world, I prefer a distributed system over svn. I > really dislike the idea of losing the history, but it shouldn''t be too > hard to import the existing history (using libsp) into whatever format > is chosen. > > Haven''t played with git, but it seems to have traction. > Rusty.Just another option: svk (http://svk.elixus.org/) It adds distribution on top of svn. I have not used it myself, but perhaps it''s an option. Best Regards, Michael Paesold _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Rik van Riel <riel@redhat.com> writes:> Since bitkeeper will become unusable for most of us in 2 > weeks, I''m wondering what revision control system Xen will > be using by then.I''d vote for either subversion or git. subversion because it is widely used (so I''d trust it not screw data) and it also seems to be the cvs successor in the open source community. git because it''s used to manage the linux kernel. Quite a few of us also do kernel work, so using the same tool for both xen and the linux kernel would be very nice. just by two cent, Gerd -- -mm seems unusually stable at present. -- akpm about 2.6.12-rc3-mm3 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 15 Jun 2005, aq wrote:> anyway we must choose one. i vote for svn (do we usually fork the > repo? i guess not).We fork all the time. It''s a common way of doing development with a distributed revision control system - people check out the upstream sources, branch them locally and still have all the benefits of revision control when it''s time to merge new upstream changes into their local repository. The reason there''s no forking in the central repositories is that it''s not needed with distributed revision control systems.> mercurial is the second choice to me.Any of the distributed systems would work fine. Central revision control would be next to useless. -- The Theory of Escalating Commitment: "The cost of continuing mistakes is borne by others, while the cost of admitting mistakes is borne by yourself." -- Joseph Stiglitz, Nobel Laureate in Economics _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Since bitkeeper will become unusable for most of us in 2 > weeks, I''m wondering what revision control system Xen will be > using by then.We''ve been expending a lot of effort experimenting with alternatives to BK... The current favourite is mercurial (hg). It''s just annoying that it currently lacks renames and per-file checkin comments. The former is particularly annoying as we''ll end up with segmented revision history for all the linux sparse tree files. Has anyone on the list got any useful experience to relate on using hg? Ian> I''d like to get familiar with the tools and get a changelog > bot written before the switchover ;) > > -- > The Theory of Escalating Commitment: "The cost of continuing > mistakes is borne by others, while the cost of admitting > mistakes is borne by yourself." > -- Joseph Stiglitz, Nobel Laureate in Economics > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 15 Jun 2005, Ian Pratt wrote:> The current favourite is mercurial (hg).Sounds good to me, I''ve seen it in action (though I''ve never actually used it myself).> It''s just annoying that it currently lacks renamesI wonder how hard it would be to get these added. Guess I''ll have to talk with Matt ;) -- The Theory of Escalating Commitment: "The cost of continuing mistakes is borne by others, while the cost of admitting mistakes is borne by yourself." -- Joseph Stiglitz, Nobel Laureate in Economics _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > It''s just annoying that it currently lacks renames > > I wonder how hard it would be to get these added. Guess I''ll > have to talk with Matt ;)Because of the way we use renames when doing linux version upgrades it would be really useful to get this added. BTW: We now run our own bkd because bkbits.net hasn''t been very reliable recently. the unstable tree is available as bk://xenbits.xensource.com/xen-unstable.bk If you don''t want to use bk, the open source bk-client and sourcepuller both work fine against it. I expect we''ll continue to mirror stuff through to BK regardless. Hopefully we''ll get a hg mirror on xenbits.xensource.com soon as well. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Andrew Thompson
2005-Jun-15 21:45 UTC
Re: [Xen-devel] bitkeeper gone in 2 weeks - which RCS?
I thought I''d let this simmer a while on the hg list, but here''s a little snippet: Ian Pratt wrote:>>>It''s just annoying that it currently lacks renames >> >>I wonder how hard it would be to get these added. Guess I''ll >>have to talk with Matt ;) > > Because of the way we use renames when doing linux version upgrades it > would be really useful to get this added.Matt Mackall wrote: > Well someone can relay to them that rename support should happen very > soon. I''m still not convinced of the value of per-file checkins (if > you need per-file checkins, your commits are too big) but I''m not > completely immune to reason. -- Andrew Thompson http://aktzero.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > Because of the way we use renames when doing linux version > > upgrades it would be really useful to get this added. > > Matt Mackall wrote: > Well someone can relay to them that rename support should > happen very soon.That''s great to hear. One of the reasons we''re keen on mercurial is that the rate of progress is so impressive.> I''m still not convinced of the value of > per-file checkins (if you need per-file checkins, your > commits are too big) but I''m not completely immune to reason.We''re intending to incrementally import our BK repo a changeset at a time, retaining as much of the meta data as possible. Since we have per-file info it seems a shame to throw it away. We may end up just creating a summary of it in the changeset comment. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christopher Li
2005-Jun-15 23:03 UTC
Re: [Xen-devel] bitkeeper gone in 2 weeks - which RCS?
On Wed, Jun 15, 2005 at 09:21:45PM -0400, Rik van Riel wrote:> On Wed, 15 Jun 2005, Matt Mackall wrote: > > > foo.c: > > comment > > > > ..should preserve things well enough. > > Agreed. I''ve never really used the "different commit > comment per file" thing in bitkeeper. Well, I used it > in the beginning, but I stopped using it after I found > out that "bk changes" didn''t actually show them anyway! >For one thing, it has performance implication of open every single file to get that per-file change log if you run the change history. I am still not convince the per file change log is very useful feature. Having more place to look is not always a good thing. Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, Jun 15, 2005 at 11:11:44PM +0100, Ian Pratt wrote:> > > Because of the way we use renames when doing linux version > > > upgrades it would be really useful to get this added. > > > > Matt Mackall wrote: > > Well someone can relay to them that rename support should > > happen very soon. > > That''s great to hear. One of the reasons we''re keen on mercurial is that > the rate of progress is so impressive.hg copy is now in tip, but there''s not much there yet except recording that a copy/rename happened.> > I''m still not convinced of the value of > > per-file checkins (if you need per-file checkins, your > > commits are too big) but I''m not completely immune to reason. > > We''re intending to incrementally import our BK repo a changeset at a > time, retaining as much of the meta data as possible. Since we have > per-file info it seems a shame to throw it away. We may end up just > creating a summary of it in the changeset comment.It''s unlikely that we''ll get the UI bits for file comments done in the next two weeks, but putting everything in the summary as: foo.c: comment ..should preserve things well enough. -- Mathematics is the supreme nostalgia of our time. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 15 Jun 2005, Matt Mackall wrote:> foo.c: > comment > > ..should preserve things well enough.Agreed. I''ve never really used the "different commit comment per file" thing in bitkeeper. Well, I used it in the beginning, but I stopped using it after I found out that "bk changes" didn''t actually show them anyway! -- The Theory of Escalating Commitment: "The cost of continuing mistakes is borne by others, while the cost of admitting mistakes is borne by yourself." -- Joseph Stiglitz, Nobel Laureate in Economics _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ronald G. Minnich
2005-Jun-16 02:37 UTC
Re: [Xen-devel] bitkeeper gone in 2 weeks - which RCS?
On Wed, 15 Jun 2005, Michael Paesold wrote:> Just another option: svk (http://svk.elixus.org/) > It adds distribution on top of svn.my ''lessons learned'' from linuxbios is if you have a research project in area X, don''t turn it into a research project into ''area X + a new SCM''. I feel we made the wrong call when we went with tla, which is nowehere near as solid as svn. I''d stick with something that has really solid usage, you can buy commercial support for, or is in every linux distro sold. ron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Rusty Russell
2005-Jun-16 02:56 UTC
Re: [Xen-devel] bitkeeper gone in 2 weeks - which RCS?
On Wed, 2005-06-15 at 17:45 -0400, Andrew Thompson wrote:> I thought I''d let this simmer a while on the hg list, but here''s a > little snippet: > > Ian Pratt wrote: > >>>It''s just annoying that it currently lacks renames > >> > >>I wonder how hard it would be to get these added. Guess I''ll > >>have to talk with Matt ;)Sorry, if we''re considering something which doesn''t support renames yet, then clearly I set the bar for maturity far too high. Hence I would recommend bzr. Actually, I don''t think that there''s any real deadline: with Xen bk outside the Larry zone, sourcepuller works fine. The pain of surviving with patches as a mechanism is small compared to the pain of choosing a system which ends up losing. So, I''d say, wait. The decision is likely to get easier in the medium term. Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Theodore Ts''o
2005-Jun-16 11:36 UTC
Re: [Xen-devel] bitkeeper gone in 2 weeks - which RCS?
On Wed, Jun 15, 2005 at 07:03:20PM -0400, Christopher Li wrote:> > Agreed. I''ve never really used the "different commit > > comment per file" thing in bitkeeper. Well, I used it > > in the beginning, but I stopped using it after I found > > out that "bk changes" didn''t actually show them anyway! > > > > For one thing, it has performance implication of open every single > file to get that per-file change log if you run the change history. > I am still not convince the per file change log is very useful > feature. Having more place to look is not always a good thing.I wouldn''t necessarily want to see the per-file change logs when looking at the change history. It''s for when you want to dive into the sources and do a more detailed look into a single changeset, or when looking at the revision history for a particular file. (i.e., when looking at the file revisions history in hg-web). - Ted _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
David Hopwood
2005-Jun-16 11:51 UTC
Re: [Xen-devel] bitkeeper gone in 2 weeks - which RCS?
Ronald G. Minnich wrote:> On Wed, 15 Jun 2005, Michael Paesold wrote: > >>Just another option: svk (http://svk.elixus.org/) >>It adds distribution on top of svn. > > my ''lessons learned'' from linuxbios is if you have a research project in > area X, don''t turn it into a research project into ''area X + a new SCM''.Absolutely. Another instance of that mistake was X = EROS (www.eros-os.org), a new SCM = OpenCM (www.opencm.org). -- David Hopwood <david.nospam.hopwood@blueyonder.co.uk> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt wrote:>>>It''s just annoying that it currently lacks renames >> >>I wonder how hard it would be to get these added. Guess I''ll >>have to talk with Matt ;) > > > Because of the way we use renames when doing linux version upgrades it > would be really useful to get this added. > > BTW: We now run our own bkd because bkbits.net hasn''t been very reliable > recently. the unstable tree is available as > bk://xenbits.xensource.com/xen-unstable.bk > If you don''t want to use bk, the open source bk-client and sourcepuller > both work fine against it. I expect we''ll continue to mirror stuff > through to BK regardless. > > Hopefully we''ll get a hg mirror on xenbits.xensource.com soon as well.This patch may be useful :) -Arun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2005-06-15 at 22:35 +0100, Ian Pratt wrote:> BTW: We now run our own bkd because bkbits.net hasn''t been very reliable > recently. the unstable tree is available as > bk://xenbits.xensource.com/xen-unstable.bk > If you don''t want to use bk, the open source bk-client and sourcepuller > both work fine against it. I expect we''ll continue to mirror stuff > through to BK regardless. > > Hopefully we''ll get a hg mirror on xenbits.xensource.com soon as well.Since it looks like things are leaning more towards mercurial at the moment, I decided to check it out. I hadn''t previously paid much attention to it since I could see that any projects were making use of it and thought it was just too early in development to be practical. I have to admit I was very impressed with several aspects of it, but it does seem to be lacking in a number of areas as well. I don''t know if this feature is important to anyone but me, but hg currently doesn''t allow you to pull a specific revision, making testing back through versions to find the point where something broke very difficult: ----------------------->* Paul Larson <plars at linuxtestproject.org> [20050620 20:14]: > >Is there currently a way to pull a specific revision? If not, is this > >feature planned to be available soon?>It is planned, but I think there is no schedule for implementation >yet.----------------------- -- Thanks, Paul Larson plars@linuxtestproject.org http://www.linuxtestproject.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, 20 Jun 2005, Paul Larson wrote:> I don''t know if this feature is important to anyone but me, but hg > currently doesn''t allow you to pull a specific revision, making testing > back through versions to find the point where something broke very > difficult:But can you clone a repository locally and undo the changes you don''t want ? -- The Theory of Escalating Commitment: "The cost of continuing mistakes is borne by others, while the cost of admitting mistakes is borne by yourself." -- Joseph Stiglitz, Nobel Laureate in Economics _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Josh Triplett
2005-Jun-20 20:54 UTC
Re: [Xen-devel] bitkeeper gone in 2 weeks - which RCS?
Paul Larson wrote:> On Wed, 2005-06-15 at 22:35 +0100, Ian Pratt wrote: >>BTW: We now run our own bkd because bkbits.net hasn''t been very reliable >>recently. the unstable tree is available as >>bk://xenbits.xensource.com/xen-unstable.bk >>If you don''t want to use bk, the open source bk-client and sourcepuller >>both work fine against it. I expect we''ll continue to mirror stuff >>through to BK regardless. >> >>Hopefully we''ll get a hg mirror on xenbits.xensource.com soon as well. > > Since it looks like things are leaning more towards mercurial at the > moment, I decided to check it out. I hadn''t previously paid much > attention to it since I could see that any projects were making use of > it and thought it was just too early in development to be practical. I > have to admit I was very impressed with several aspects of it, but it > does seem to be lacking in a number of areas as well.>> I don''t know if this feature is important to anyone but me, but hg > currently doesn''t allow you to pull a specific revision, making testing > back through versions to find the point where something broke very > difficult:Mercurial looks further along than some of the other new SCM projects (such as bzr), and it does look usable, but the ability to diff previous revisions does seem rather essential for a revision control system. :) On the other hand, the easy interoperation with git would be helpful. Another possible option might be Bazaar (baz, not bzr). It uses the Arch format and interoperates with Arch, but the user-interface is far more usable, and has a relatively low learning curve from CVS/SVN/etc (unlike tla). It has all the distributed features one might want, and it has the advantage that all the tools designed around arch still work. There''s a useful quick-start guide for Bazaar at http://usefulinc.com/edd/blog/contents/2005/05/04-bazaar/read . - Josh Triplett _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Andrew Thompson
2005-Jun-20 21:01 UTC
Re: [Xen-devel] bitkeeper gone in 2 weeks - which RCS?
Paul Larson wrote:> On Wed, 2005-06-15 at 22:35 +0100, Ian Pratt wrote: > I don''t know if this feature is important to anyone but me, but hg > currently doesn''t allow you to pull a specific revision, making testing > back through versions to find the point where something broke very > difficult: > ----------------------- > >>* Paul Larson <plars at linuxtestproject.org> [20050620 20:14]: >> >>>Is there currently a way to pull a specific revision? If not, is this >>>feature planned to be available soon? > > >>It is planned, but I think there is no schedule for implementation >>yet.The question you asked, and the feature you are wanting are two different things. If you clone/init a repository from the source(or a mirror of it), you get everything in it. If you want to then look at a specific revision of the code, you: hg checkout -C [revision] -- Andrew Thompson http://aktzero.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Rik van Riel wrote:> On Mon, 20 Jun 2005, Paul Larson wrote: > > >>I don''t know if this feature is important to anyone but me, but hg >>currently doesn''t allow you to pull a specific revision, making testing >>back through versions to find the point where something broke very >>difficult: > > > But can you clone a repository locally and undo the > changes you don''t want ? >This was on xen-devel a while ago. The argument that Matt made was that you can never undo things in a distributed system (because someone else could''ve pulled from you before you did undo). hg co <rev> is not good enough for now? -Arun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, 20 Jun 2005, Arun Sharma wrote:> hg co <rev> is not good enough for now?Even better. Good point. -- The Theory of Escalating Commitment: "The cost of continuing mistakes is borne by others, while the cost of admitting mistakes is borne by yourself." -- Joseph Stiglitz, Nobel Laureate in Economics _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, 2005-06-20 at 17:01 -0400, Andrew Thompson wrote:> Paul Larson wrote: > > On Wed, 2005-06-15 at 22:35 +0100, Ian Pratt wrote: > > I don''t know if this feature is important to anyone but me, but hg > > currently doesn''t allow you to pull a specific revision, making testing > > back through versions to find the point where something broke very > > difficult: > > ----------------------- > > > >>* Paul Larson <plars at linuxtestproject.org> [20050620 20:14]: > >> > >>>Is there currently a way to pull a specific revision? If not, is this > >>>feature planned to be available soon? > > > > > >>It is planned, but I think there is no schedule for implementation > >>yet. > > The question you asked, and the feature you are wanting are two > different things. > > If you clone/init a repository from the source(or a mirror of it), you > get everything in it. If you want to then look at a specific revision of > the code, you: hg checkout -C [revision]Ok, good. That seems to work just fine, sorry if I phrased it badly. -- Thanks, Paul Larson plars@linuxtestproject.org http://www.linuxtestproject.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Soh Tk-r28629
2005-Jun-21 00:16 UTC
RE: [Xen-devel] bitkeeper gone in 2 weeks - which RCS?
> -----Original Message----- > If you clone/init a repository from the source(or a mirror of it), you > get everything in it. If you want to then look at a specific revision of > the code, you: hg checkout -C [revision]How can I tell what revision is currently checked out this directory? ''hg id'' seems to give too little information. Can I then make changes to this revision, then commit, and later update to tip? What are the commands to achieve this? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Jun 21, 2005 at 08:16:59AM +0800, Soh Tk-r28629 wrote:> > -----Original Message----- > > If you clone/init a repository from the source(or a mirror of it), you > > get everything in it. If you want to then look at a specific revision of > > the code, you: hg checkout -C [revision] > > How can I tell what revision is currently checked out this directory? ''hg id'' seems to give too little information.hg parents should help.> Can I then make changes to this revision, then commit, and later update to tip? What are the commands to achieve this?Almost. When you commit, your commit becomes the new tip. So you''ll need the heads command here to find the other head you want to merge with. hg commit hg heads hg up <id> And this will usually imply a branch merge, so you''ll need: hg up -m <id> -- Mathematics is the supreme nostalgia of our time. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel