bitkeeper gone in 2 weeks - which RCS?

bitkeeper gone in 2 weeks - which RCS?

[Rik van Riel]

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

Re: bitkeeper gone in 2 weeks - which RCS?

[Paul Larson]

[-- Attachment #1.1: Type: text/plain, Size: 565 bytes --]

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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: bitkeeper gone in 2 weeks - which RCS?

[Ronald G. Minnich]

v9fs moved to git and it's been pretty fine.

ron

Re: bitkeeper gone in 2 weeks - which RCS?

[Arun Sharma]

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

Re: bitkeeper gone in 2 weeks - which RCS?

[Paul Larson]

[-- Attachment #1.1: Type: text/plain, Size: 600 bytes --]

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/hg
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
-- 
Thanks,
Paul Larson
plars@linuxtestproject.org
http://www.linuxtestproject.org

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: bitkeeper gone in 2 weeks - which RCS?

[Ronald G. Minnich]

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

Re: bitkeeper gone in 2 weeks - which RCS?

[Arun Sharma]

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

Re: bitkeeper gone in 2 weeks - which RCS?

[Arun Sharma]

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

	-Arun

Re: bitkeeper gone in 2 weeks - which RCS?

[aq]

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

Re: bitkeeper gone in 2 weeks - which RCS?

[Rusty Russell]

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

Re: bitkeeper gone in 2 weeks - which RCS?

[Michael Paesold]

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

Re: bitkeeper gone in 2 weeks - which RCS?

[Gerd Knorr]

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

Re: bitkeeper gone in 2 weeks - which RCS?

[Rik van Riel]

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

RE: bitkeeper gone in 2 weeks - which RCS?

[Ian Pratt]

> 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
> 

RE: bitkeeper gone in 2 weeks - which RCS?

[Rik van Riel]

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 renames

I 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

RE: bitkeeper gone in 2 weeks - which RCS?

[Ian Pratt]

> > 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

Re: bitkeeper gone in 2 weeks - which RCS?

[Andrew Thompson]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

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/

[-- Attachment #2: andrewkt.vcf --]
[-- Type: text/x-vcard, Size: 153 bytes --]

begin:vcard
fn:Andrew Thompson
n:Thompson;Andrew
email;internet:andrewkt@aktzero.com
x-mozilla-html:FALSE
url:http://aktzero.com/
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: bitkeeper gone in 2 weeks - which RCS?

[Ian Pratt]

> > 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

Re: bitkeeper gone in 2 weeks - which RCS?

[Christopher Li]

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 

Re: bitkeeper gone in 2 weeks - which RCS?

[Matt Mackall]

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.

Re: bitkeeper gone in 2 weeks - which RCS?

[Rik van Riel]

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

Re: bitkeeper gone in 2 weeks - which RCS?

[Ronald G. Minnich]

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

Re: bitkeeper gone in 2 weeks - which RCS?

[Rusty Russell]

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

Re: bitkeeper gone in 2 weeks - which RCS?

[Theodore Ts'o]

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

Re: bitkeeper gone in 2 weeks - which RCS?

[David Hopwood]

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>

Re: bitkeeper gone in 2 weeks - which RCS?

[Arun Sharma]

[-- Attachment #1: Type: text/plain, Size: 744 bytes --]

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

[-- Attachment #2: hg.patch --]
[-- Type: text/plain, Size: 632 bytes --]

--- a/xen/Makefile	Thu Jun 16 18:18:15 2005
+++ b/xen/Makefile	Thu Jun 16 11:34:24 2005
@@ -77,7 +77,7 @@
 	    -e 's/@@version@@/$(XEN_VERSION)/g' \
 	    -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \
 	    -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \
-	    -e 's!@@changeset@@!$(shell bk changes -nd':D: :T: :REV: :MD5KEY:' -r+ 2>/dev/null || echo information unavailable)!g' \
+	    -e 's!@@changeset@@!$(shell bk changes -nd':D: :T: :REV: :MD5KEY:' -r+ 2>/dev/null || hg -q tip 2>/dev/null || echo information unavailable)!g' \
 	    < include/xen/compile.h.in > $@.new
 	@cat include/xen/banner.h >> $@.new
 	@mv -f $@.new $@

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: bitkeeper gone in 2 weeks - which RCS?

[Paul Larson]

[-- Attachment #1.1: Type: text/plain, Size: 1511 bytes --]

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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: bitkeeper gone in 2 weeks - which RCS?

[Rik van Riel]

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

Re: bitkeeper gone in 2 weeks - which RCS?

[Josh Triplett]

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

Re: bitkeeper gone in 2 weeks - which RCS?

[Andrew Thompson]

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]

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/

[-- Attachment #2: andrewkt.vcf --]
[-- Type: text/x-vcard, Size: 153 bytes --]

begin:vcard
fn:Andrew Thompson
n:Thompson;Andrew
email;internet:andrewkt@aktzero.com
x-mozilla-html:FALSE
url:http://aktzero.com/
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: bitkeeper gone in 2 weeks - which RCS?

[Arun Sharma]

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

Re: bitkeeper gone in 2 weeks - which RCS?

[Rik van Riel]

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

Re: bitkeeper gone in 2 weeks - which RCS?

[Paul Larson]

[-- Attachment #1.1: Type: text/plain, Size: 1154 bytes --]

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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: bitkeeper gone in 2 weeks - which RCS?

[Soh Tk-r28629]

> -----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?

Re: bitkeeper gone in 2 weeks - which RCS?

[Matt Mackall]

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.