Git vs Monotone

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Git vs Monotone

Sverre Rabbelier
Heya,

I just read this blog post [0] in which one of the Pidgin devs sheds
his light on their 'tool choice'. In the post he mentions the
following figures:

"I don't mind the database, myself. I have 11 working copies
(checkouts) from my single pidgin database (8 distinct branches, plus
duplicates of the last three branches I worked on or tested with).
Each clean checkout (that is, a checkout prior to running autogen.sh
and building) is approximately 61 MB. If this were SVN, each working
copy would be approximately 122 MB due to svn keeping a pristine copy
of every file to facilitate 'svn diff' and 'svn revert' without
needing to contact the server the working copy was pulled from. Now,
let's add that up. For SVN, I would have 11 times 122 MB, or 1342 MB,
just in working copies. For monotone, I have 11 times 61 MB for the
working copies (671 MB), plus 229 MB for the database, for a grand
total of 900 MB. For me, this is an excellent bargain, as I save 442
MB of disk space thanks to the monotone model. For another compelling
comparison that's sure to ruffle a few feathers, let's compare to git.
If I clone the git mirror of our monotone repository, I find a
checkout size of 148 MB after git-repack--running git-gc also
increased the size by 2 MB, but I'll stick with the initial checkout
size for fairness. If I multiply this by my 11 checkouts, I will have
1628 MB. This is even more compelling for me, as I now save 728 MB of
disk space with monotone."

I'm in the process of cloning the repo myself, and will check if doing
a more aggressive (high --window and --depth values) repack will get
us below that 148, but I'm thinking it's just that big a repo. Anyway,
it seems git is getting screwed over in this post because he is not
taking advantage of git's object-database-sharing capabilities. Am i
right in thinking that with git-new-workdir we would end up at
61*11+148 = 819MB? (Which would actually put us below monotone by
80MB.) Not that I care much whether monotone or git is smaller in disk
size, I'm just curious if we indeed offer this capability? Perhaps
someone with more knowledge of git-new-workdir could shed a light?

[0] http://theflamingbanker.blogspot.com/2008/07/holy-war-of-tool-choice.html

--
Cheers,

Sverre Rabbelier
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Git vs Monotone

Stephen R. van den Berg
Sverre Rabbelier wrote:
>If I clone the git mirror of our monotone repository, I find a
>checkout size of 148 MB after git-repack--running git-gc also
>increased the size by 2 MB, but I'll stick with the initial checkout
>size for fairness. If I multiply this by my 11 checkouts, I will have
>1628 MB. This is even more compelling for me, as I now save 728 MB of
>disk space with monotone."

You have at least two options to reduce diskspace:
a. Clone once from remote, then clone from that clone, it should
   hardlink the larger packfiles to the initial clone and therefore not
   cost you a lot.
b. Clone once from remote, and create 11 branches inside the new cloned
   repo.  Switch branches while doing development.

Most git users pick b.  It's easier to work with.  Having 11 unpacked
repos means that all the object files in those trees are almost up to
date, but it adds to the complexity of comparing changes and merging
changes between branches.  The compilation speed can be increased with
ccache if need be.
--
Sincerely,
           Stephen R. van den Berg.
"There are three types of people in this world: those who make things happen,
 those who watch things happen and those who wonder what happened."
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Git vs Monotone

Petr Baudis
On Thu, Jul 31, 2008 at 08:33:17PM +0200, Stephen R. van den Berg wrote:

> Sverre Rabbelier wrote:
> >If I clone the git mirror of our monotone repository, I find a
> >checkout size of 148 MB after git-repack--running git-gc also
> >increased the size by 2 MB, but I'll stick with the initial checkout
> >size for fairness. If I multiply this by my 11 checkouts, I will have
> >1628 MB. This is even more compelling for me, as I now save 728 MB of
> >disk space with monotone."
>
> You have at least two options to reduce diskspace:
> a. Clone once from remote, then clone from that clone, it should
>    hardlink the larger packfiles to the initial clone and therefore not
>    cost you a lot.
> b. Clone once from remote, and create 11 branches inside the new cloned
>    repo.  Switch branches while doing development.
>
> Most git users pick b.  It's easier to work with.  Having 11 unpacked
> repos means that all the object files in those trees are almost up to
> date, but it adds to the complexity of comparing changes and merging
> changes between branches.  The compilation speed can be increased with
> ccache if need be.

c. Still clone from the remote, but set up alternates to a single
local "reference repository". Then all common objects will be stored
only once in this reference repository. The advantage to (a) is that
your remotes are actually set up sensibly.

(Note that the blog post talks about .git + checkout sizes, in case
someone got confused like I did, counting only .git. :-)

--
                                Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name.  -- Ken Thompson and Dennis M. Ritchie
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Git vs Monotone

Jeff King
In reply to this post by Sverre Rabbelier
On Thu, Jul 31, 2008 at 08:13:59PM +0200, Sverre Rabbelier wrote:

> If I clone the git mirror of our monotone repository, I find a
> checkout size of 148 MB after git-repack--running git-gc also
> increased the size by 2 MB, but I'll stick with the initial checkout
> size for fairness. If I multiply this by my 11 checkouts, I will have
> 1628 MB. This is even more compelling for me, as I now save 728 MB of
> disk space with monotone."

Yikes. This is not even remotely a fair comparison to monotone, which is
keeping a central db.

> I'm in the process of cloning the repo myself, and will check if doing
> a more aggressive (high --window and --depth values) repack will get
> us below that 148, but I'm thinking it's just that big a repo. Anyway,

It's much better than that. I just cloned

  git://github.com/felipec/pidgin-clone.git

and the _whole thing_ is 148M, including the working tree. His object db
is only 88M. So he can do his 11 trees in 61 * 11 + 88 = 759M, saving
141M over monotone.

And I am repacking with insane depth and window right now to see if we
can get it smaller (though really, it is not that big a deal, since the
size is dominated by his 11 working trees).

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

RE: Git vs Monotone

Craig L. Ching
 

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Jeff King
> Sent: Thursday, July 31, 2008 2:02 PM
> To: [hidden email]
> Cc: Git Mailinglist
> Subject: Re: Git vs Monotone
>
> On Thu, Jul 31, 2008 at 08:13:59PM +0200, Sverre Rabbelier wrote:
>
> > If I clone the git mirror of our monotone repository, I find a
> > checkout size of 148 MB after git-repack--running git-gc also
> > increased the size by 2 MB, but I'll stick with the initial
> checkout
> > size for fairness. If I multiply this by my 11 checkouts, I
> will have
> > 1628 MB. This is even more compelling for me, as I now save
> 728 MB of
> > disk space with monotone."
>
> Yikes. This is not even remotely a fair comparison to
> monotone, which is keeping a central db.
>
I think it is a fair comparison, but as you point out, the author is
doing the comparison wrong.  Monotone's "central db" (as you call it) is
really equivalent to git's object database.

> > I'm in the process of cloning the repo myself, and will
> check if doing
> > a more aggressive (high --window and --depth values) repack
> will get
> > us below that 148, but I'm thinking it's just that big a
> repo. Anyway,
>
> It's much better than that. I just cloned
>
>   git://github.com/felipec/pidgin-clone.git
>
> and the _whole thing_ is 148M, including the working tree.
> His object db is only 88M. So he can do his 11 trees in 61 *
> 11 + 88 = 759M, saving 141M over monotone.
>
Right, that's been my experience too, that git is smaller than monotone.
The author just needs to compare eqivalent concepts ;-)

> -Peff
> --

Cheers,
Craig
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Git vs Monotone

Linus Torvalds-3
In reply to this post by Sverre Rabbelier


On Thu, 31 Jul 2008, Sverre Rabbelier wrote:
>
> I just read this blog post [0] in which one of the Pidgin devs sheds
> his light on their 'tool choice'. In the post he mentions the
> following figures:

Don't even bother. The guy is apparently not even trying to work with his
tools, he just has an agenda to push.

Quite frankly, anybody who wants to stay with monotone, we should
_encourage_ them. They add nothing to any possible project, because they
are clearly not very intelligent.

The guy is apparently happy using a single database for monotone (which
apparently has a database that is two times the size of the git one), but
then doesn't want to use a single database for git, but wants to force a
full clone for each. Not to mention that in git, you'd normally not do 11
clones to begin with, you'd just do 11 branches in one repo.

So there is no point discussing things with people like that. If he wants
to skew things in monotone's favor, he can do it. Let him.

                        Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Git vs Monotone

Sverre Rabbelier
In reply to this post by Jeff King
On Thu, Jul 31, 2008 at 21:02, Jeff King <[hidden email]> wrote:
> and the _whole thing_ is 148M, including the working tree. His object db
> is only 88M. So he can do his 11 trees in 61 * 11 + 88 = 759M, saving
> 141M over monotone.

Yeah, that's rather unfair indeed, counting that way he'd have to add
the 229MB for the Monotone db too ;).

> And I am repacking with insane depth and window right now to see if we
> can get it smaller (though really, it is not that big a deal, since the
> size is dominated by his 11 working trees).

I repacked with --depth=100 and --window=100, I tried out 500 at first
but it was just insanely slow (on a VM with one 2.4Ghz Core
available). This resulted in a .git dir of 76MB. With that dir I did
the following:
$mkdir pidgins
$git clone --no-hardlinks --bare pidgin pidgin-bare
$mv pidgin-bare pidgins
$cd pidgins
$for i in 1 2 3 4 5 6 7 8 9 10 11; do git clone pidgin-bare pidgin$i; done
$ du -sh .
742M    .

So... monotone, eat your heart out ;).

--
Cheers,

Sverre Rabbelier
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Git vs Monotone

Ted Ts'o
In reply to this post by Sverre Rabbelier
On Thu, Jul 31, 2008 at 08:13:59PM +0200, Sverre Rabbelier wrote:
>
> I just read this blog post [0] in which one of the Pidgin devs sheds
> his light on their 'tool choice'. In the post he mentions the
> following figures:

The main thing this proves was that the Pidgin devs were most familiar
with Monotone, and weren't sufficiently familiar with git; hence, they
didn't know how to do a fair comparison.  First of all, sure, if they
are willing to use a single working directory and want to switch
between branches using "git checkout", that works well.  But suppose
they really want separate working directories.  The simplist and
easist way is to use "git clone -s".

So if they do:

git clone git://github.com/felipec/pidgin-clone.git pidgin
git clone -s pidgin clone-1
git clone -s pidgin clone-2
git clone -s pidgin clone-3
git clone -s pidgin clone-4
git clone -s pidgin clone-5
git clone -s pidgin clone-6
git clone -s pidgin clone-7
git clone -s pidgin clone-8
git clone -s pidgin clone-9
git clone -s pidgin clone-10

The net disk usage is 746 megabytes, as compared to the 900 megabytes
claimed in the blog post.  The main difference is the git database is
only takes 87 megabytes, compared to the 229 megabytes for the
Monotone database.  The main issue is the pidgin developers simply
didn't know how to use the -s flag so they didn't need to duplicate
the git database for every single clone.

Shrug; whatever, I've always said the biggest issue for any tool is
what the developers are familiar with.  It may be that monotone was
the right choice for the pidgin core developers, if they weren't
familiar enough with git.

                                                - Ted
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

RE: Git vs Monotone

Craig L. Ching
In reply to this post by Linus Torvalds-3
 

> [mailto:[hidden email]] On Behalf Of Linus Torvalds
> Sent: Thursday, July 31, 2008 2:18 PM
> Subject: Re: Git vs Monotone
>
> On Thu, 31 Jul 2008, Sverre Rabbelier wrote:
> >
> The guy is apparently happy using a single database for
> monotone (which apparently has a database that is two times
> the size of the git one), but then doesn't want to use a
> single database for git, but wants to force a full clone for
> each. Not to mention that in git, you'd normally not do 11
> clones to begin with, you'd just do 11 branches in one repo.
>

Having come from monotone to git recently, I have to say that it isn't
immediately obvious how you get the single database for git a la
monotone (with remotes that point to the right place, etc.).  At first,
I also thought that you didn't share the object database on clones and I
had to discover that myself.  It's possible that I'm just an idiot too
;-)

> So there is no point discussing things with people like that.
> If he wants to skew things in monotone's favor, he can do it.
> Let him.
>

It's possible he's doing that, but it's also possible he just isn't that
familiar with git.

> Linus
> --

Cheers,
Craig
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)

Craig L. Ching
In reply to this post by Linus Torvalds-3
 

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Linus Torvalds
> Sent: Thursday, July 31, 2008 2:18 PM

> single database for git, but wants to force a full clone for
> each. Not to mention that in git, you'd normally not do 11
> clones to begin with, you'd just do 11 branches in one repo.
>

I have a question about this.  I asked this awhile back and didn't
really get any satisfactory answers except to use git-new-workdir, which
makes git behave a lot like monotone.  In our workflow, we do create
branches for nearly everything, but we do find that we have a need to
keep the build artifacts of those branches isolated from each other
because rebuilding is expensive.  IOW, we have this sort of workflow:

git checkout A
[work on A, build, test, do some commits]
git checkout B
[work on B, build, test, do some commits]
git checkout A
[work on A, re-build, test, do some commits]

We find ourselves constantly having to shift gears and work on other
things in the middle of whatever it is we're currently working on.  For
instance, in the scenario above, A might be branch that contains a
feature going into our next release.  B might be a bugfix and takes
priority over A, so you have to leave A as-is and start work on B.  When
I come back to work on A, I have to rebuild A to continue working, and
that's just too expensive for us.  So we use the monotone-like
new-workdir which allows us to save those build artifacts.

So, that said, I ask again, am I missing something?  Is there a better
way to do this?  How do the kernel developers do this, surely they're
switching branches back and forth having to build in-between?

> Linus
> --
> To unsubscribe from this list: send the line "unsubscribe
> git" in the body of a message to [hidden email]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Cheers,
Craig
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

RE: Git vs Monotone

Linus Torvalds-3
In reply to this post by Craig L. Ching


On Thu, 31 Jul 2008, Craig L. Ching wrote:
>
> It's possible he's doing that, but it's also possible he just isn't that
> familiar with git.

Possible. But it really sounded like he didn't even try. Because quite
frankly, if he had even bothered to _try_, he wouldn't have gotten the
numbers he got.

The fact is, even without "-s", a local clone will do hardlinks for the
database. And since the original pack-file is marked as a 'keep' file,
that original pack-file won't even be broken apart.

So literally, if he had just bothered to even _try_ the git setup, he'd
have noticed that git actually uses less disk than monotone would do. But
it sounds like he didn't even try it.

So completely ignoring the fact that you could do a single database with
git, and completely ignoring the fact that with git you'd probably use
branches for at least some of those 11 repos anyway, he'd _still_ have had
less disk space used by git unless he would do something intentionally odd
(like clone all the repositories over the network separately).

                        Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)

Linus Torvalds-3
In reply to this post by Craig L. Ching


On Thu, 31 Jul 2008, Craig L. Ching wrote:

>
> We find ourselves constantly having to shift gears and work on other
> things in the middle of whatever it is we're currently working on.  For
> instance, in the scenario above, A might be branch that contains a
> feature going into our next release.  B might be a bugfix and takes
> priority over A, so you have to leave A as-is and start work on B.  When
> I come back to work on A, I have to rebuild A to continue working, and
> that's just too expensive for us.  So we use the monotone-like
> new-workdir which allows us to save those build artifacts.
>
> So, that said, I ask again, am I missing something?  Is there a better
> way to do this?  How do the kernel developers do this, surely they're
> switching branches back and forth having to build in-between?

Sure, if you want to keep the build tree around, you would probably not
use branches.

But yes, then you'd likely do "git clone -s" with some single "common
point" or use "git worktree". And even if you don't use "-s", you should
_still_ effectively share at least all the old history (which tends to be
the bulk) thanks to even a default "git clone" will just hardlink the
pack-files.

So literally, if you do

        git clone <cntral-repo-over-network> <local>

and then do

        git clone <local> <otherlocal>
        git clone <local> <thirdlocal>

then all of those will all share the initial pack-file on-disk. Try it.

(You may then want to edit the "origin" branch info in the .git/config to
point to the network one etc, of course).

Oh, and to make sure I'm not lying I actually did test this, but I also
noticed that "git clone" no longer marks the initial pack-file with
"keep", so it looks like "git gc" will then break the link. That's sad. I
wonder when that changed, or maybe I'm just confused and it never did.

Junio?

                Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)

Shawn Pearce
Linus Torvalds <[hidden email]> wrote:
>
> Oh, and to make sure I'm not lying I actually did test this, but I also
> noticed that "git clone" no longer marks the initial pack-file with
> "keep", so it looks like "git gc" will then break the link. That's sad. I
> wonder when that changed, or maybe I'm just confused and it never did.

It was a bug in git-clone that we were recording the .keep file on
initial clone.  We left the lock file in place after the fetch pack
call was done, but didn't remove it after the refs were updated.

If we want to go back to .keep'ing the original pack creating
during clone it probably should be threshold based.  For many
smaller projects with only a 25M pack (or less) there is no point
in .keep'ing that first pack.  For larger projects where the pack
is over a few hundred megabytes, then yea, maybe there is value
in .keep'ing it during clone.

--
Shawn.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Git vs Monotone

Junio C Hamano
In reply to this post by Linus Torvalds-3
Linus Torvalds <[hidden email]> writes:

> ... And since the original pack-file is marked as a 'keep' file,
> that original pack-file won't even be broken apart.

Oops, isn't that something we fixed recently as a "bug"?

> So completely ignoring the fact that you could do a single database with
> git, and completely ignoring the fact that with git you'd probably use
> branches for at least some of those 11 repos anyway, he'd _still_ have had
> less disk space used by git unless he would do something intentionally odd
> (like clone all the repositories over the network separately).

Well, people are not perfect and they are free to express their opinions
based on faulty understanding of reality on their blogs.  The right things
to do are (1) ignore them on the list and not waste many people's time,
and/or (2) educate them, but in private or in a circle where many other
similar ignorants benefit from such education.  That is not here but
perhaps on #monotone channel?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Git vs Monotone

Linus Torvalds-3


On Thu, 31 Jul 2008, Junio C Hamano wrote:

> Linus Torvalds <[hidden email]> writes:
>
> > ... And since the original pack-file is marked as a 'keep' file,
> > that original pack-file won't even be broken apart.
>
> Oops, isn't that something we fixed recently as a "bug"?

Ehh, apparently. I had thought it was a feature (not that it was me who
implemented it), and didn't realize that others thought it was a bug.
Oops.

The default *.keep file was _wonderful_ for cloning a large tree onto a
small machine. It did exactly the right thing (never mind any shared
repositories - it just made repacking much more reasonable).

So maybe it was unintentional (a "bug"), but I had always seen it as being
something good.

                        Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Git vs Monotone

Jeff King
In reply to this post by Sverre Rabbelier
On Thu, Jul 31, 2008 at 09:19:41PM +0200, Sverre Rabbelier wrote:

> I repacked with --depth=100 and --window=100, I tried out 500 at first
> but it was just insanely slow (on a VM with one 2.4Ghz Core
> available). This resulted in a .git dir of 76MB. With that dir I did
> the following:

I tried 200/200 and got a 74M packfile. So I think we're getting into
diminishing returns.

> $ du -sh .
> 742M    .
>
> So... monotone, eat your heart out ;).

:)

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

RE: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)

Craig L. Ching
In reply to this post by Linus Torvalds-3

> From: Linus Torvalds [mailto:[hidden email]]
> Sent: Thursday, July 31, 2008 3:09 PM
>
> Sure, if you want to keep the build tree around, you would
> probably not use branches.
>

I think we'd still use branches, but we just need to isolate their
workdirs from each other.

> But yes, then you'd likely do "git clone -s" with some single
> "common point" or use "git worktree". And even if you don't
> use "-s", you should _still_ effectively share at least all
> the old history (which tends to be the bulk) thanks to even a
> default "git clone" will just hardlink the pack-files.
>
> So literally, if you do
>
> git clone <cntral-repo-over-network> <local>
>
> and then do
>
> git clone <local> <otherlocal>
> git clone <local> <thirdlocal>
>
> then all of those will all share the initial pack-file
> on-disk. Try it.
>
> (You may then want to edit the "origin" branch info in the
> .git/config to point to the network one etc, of course).
>

Yes, thank you for the explanation.  Having used git a fair amount now,
that makes perfect sense to me, in fact, it sounds a lot like
git-new-workdir, but I think I'll change our use of git-new-workdir to
something more "core" git.  It seems to me that maybe this is something
that could be documented more prominently?  Or maybe it is and I've just
missed it.  This would have saved me a lot of time originally to be
sure.

> Oh, and to make sure I'm not lying I actually did test this,
> but I also noticed that "git clone" no longer marks the
> initial pack-file with "keep", so it looks like "git gc" will
> then break the link. That's sad. I wonder when that changed,
> or maybe I'm just confused and it never did.
>

What's the consequence of that then?  Because of that, would you say
"don't gc your master local repo until all derived repos are merged?"
If that link is broken is it just a loss of space? Or is it more?

> Linus
>

Thanks again!

Cheers,
Craig
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

RE: Git vs Monotone

Blum, Robert
In reply to this post by Linus Torvalds-3

>The fact is, even without "-s", a local clone will do hardlinks for the
>database. And since the original pack-file is marked as a 'keep' file,
>that original pack-file won't even be broken apart.

Then again, Pidgin is, among other things, a Windows project. I.e. hardlinks are not exactly trivial. There's a good chance nobody jumped through the hoops of junction points for git on win32... (Somebody correct me if I'm wrong)

>So literally, if he had just bothered to even _try_ the git setup, he'd
>have noticed that git actually uses less disk than monotone would do. But
>it sounds like he didn't even try it.

Well, he *did* try it, for *one* repository. He just didn't know that there's a better way than having 11 clones. And I lay the blame for that squarely at the git documentation ;)

Yes, I know, why don't I make it better...?

Because I'm fairly new to git and would feel like an idiot 'documenting' something that I feel I've only scratched the surface of. I do expect to write a few uninformed rants on my blog, though. And maybe at some point, I can contribute to actual docs :)

Either way, it's another interesting data point for all of us still comparing DVCSs. I just wish he had comments on his blog so somebody could inform him that he's mistaken...


 - Robert
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)

Björn Steinbrink
In reply to this post by Linus Torvalds-3
On 2008.07.31 13:09:09 -0700, Linus Torvalds wrote:

>
>
> On Thu, 31 Jul 2008, Craig L. Ching wrote:
> >
> > We find ourselves constantly having to shift gears and work on other
> > things in the middle of whatever it is we're currently working on.  For
> > instance, in the scenario above, A might be branch that contains a
> > feature going into our next release.  B might be a bugfix and takes
> > priority over A, so you have to leave A as-is and start work on B.  When
> > I come back to work on A, I have to rebuild A to continue working, and
> > that's just too expensive for us.  So we use the monotone-like
> > new-workdir which allows us to save those build artifacts.
> >
> > So, that said, I ask again, am I missing something?  Is there a better
> > way to do this?  How do the kernel developers do this, surely they're
> > switching branches back and forth having to build in-between?
>
> Sure, if you want to keep the build tree around, you would probably not
> use branches.
>
> But yes, then you'd likely do "git clone -s" with some single "common
> point" or use "git worktree". And even if you don't use "-s", you should
> _still_ effectively share at least all the old history (which tends to be
> the bulk) thanks to even a default "git clone" will just hardlink the
> pack-files.
>
> So literally, if you do
>
> git clone <cntral-repo-over-network> <local>

Hum, I guess I'm just missing something and prepare to get flamed, but
wouldn't you want that one to be bare? Otherwise, the other clones won't
see all of the original repo's branches, right?

Maybe even better:

mkdir local-mirror
cd local-mirror
git --bare init
git remote add -f --mirror origin <central-repo-over-network>

A cronjob (or whatever) could keep the local mirror up-to-date and the
other repos can fetch from there. Pushing would need to go to a
different remote then though.. Humm... Maybe not worth the trouble for a
bit of additional object sharing.

Björn
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)

Sean Estabrooks
In reply to this post by Craig L. Ching
On Thu, 31 Jul 2008 14:48:21 -0500
"Craig L. Ching" <[hidden email]> wrote:

> I have a question about this.  I asked this awhile back and didn't
> really get any satisfactory answers except to use git-new-workdir, which
> makes git behave a lot like monotone.  In our workflow, we do create
> branches for nearly everything, but we do find that we have a need to
> keep the build artifacts of those branches isolated from each other
> because rebuilding is expensive.  IOW, we have this sort of workflow:

Is there a problem using git-new-workdir?  It sounds like it does
exactly what you want.

> We find ourselves constantly having to shift gears and work on other
> things in the middle of whatever it is we're currently working on.  For
> instance, in the scenario above, A might be branch that contains a
> feature going into our next release.  B might be a bugfix and takes
> priority over A, so you have to leave A as-is and start work on B.  When
> I come back to work on A, I have to rebuild A to continue working, and
> that's just too expensive for us.  So we use the monotone-like
> new-workdir which allows us to save those build artifacts.
>
> So, that said, I ask again, am I missing something?  Is there a better
> way to do this?  How do the kernel developers do this, surely they're
> switching branches back and forth having to build in-between?

A decent build system will only compile the source files that actually
changed when switching branches.  Couple that with a compiler cache
(such as ccache) and switching between branches in the kernel or git
project usually isn't prohibitively time consuming.

Sean
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
12