From: mjt@nysv.org
To: Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2004@gmx.net>
Cc: Valdis.Kletnieks@vt.edu, Hans Reiser <reiser@namesys.com>,
reiserfs-list@namesys.com
Subject: Re: On a free repacker
Date: Mon, 24 May 2004 23:47:51 +0300 [thread overview]
Message-ID: <20040524204751.GC4990@nysv.org> (raw)
In-Reply-To: <40B25DF0.2090400@gmx.net>
On Mon, May 24, 2004 at 10:41:20PM +0200, Carl-Daniel Hailfinger wrote:
>
># bk clone bk://some.url/of/the/project
>and you have a directory "project"
># cd project
># ./configure; make; make install
>for updates:
># cd project
># bk pull
>some projects may have a default of source not checked out, do it now
># bk -r get
I think this script is pretty much fubar :)
Oh, and mjt.nysv.org is down, don't even try to download this or anything
else, it will fail.[1]
>Can it get simpler than this? I'm truly interested in anything that makes
>my life simpler.
Lots of switches which affect what is transferred. That may be versatility
but I think it's useless. SVN is just svn update and there you have it.
That is achieved with clone, pull and -r get in BK.
How does BK do diffs? SVN is svn diff -r145:146 and it's there.
SVN's bigger problem seems to be that files are actually copied when
they're tagged. I love that, but I could see it flooding the hard drive.
Apparently they're just tagged in the server-side database, but it's
transparent copying.
That's a fair trade-off for anything CVS can throw at me ;)
I have to admit, though, that I lack experience in BK, and may find the
options, switches and knobs simpler if I got into it. But I don't see
the need...
[1]
Damn how much I hate computers sometimes. Like I wouldn't have more pressing
matters than some broken python cgi...
--
mjt
next prev parent reply other threads:[~2004-05-24 20:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-19 19:28 On a free repacker mjt
2004-05-20 17:28 ` Hans Reiser
2004-05-20 18:40 ` mjt
2004-05-22 2:32 ` Hans Reiser
2004-05-21 15:48 ` Redeeman
2004-05-22 2:57 ` Hans Reiser
2004-05-21 16:02 ` Redeeman
2004-05-21 18:49 ` mjt
2004-05-21 18:44 ` mjt
2004-05-21 19:02 ` Valdis.Kletnieks
2004-05-24 20:30 ` mjt
2004-05-24 20:41 ` Carl-Daniel Hailfinger
2004-05-24 20:47 ` mjt [this message]
2004-05-24 21:23 ` Carl-Daniel Hailfinger
2004-05-25 7:51 ` mjt
2004-05-25 1:12 ` Michael Milverton
2004-05-24 21:54 ` Valdis.Kletnieks
2004-05-27 4:10 ` Hans Reiser
2004-05-21 19:15 ` Mike Benoit
2004-05-21 19:36 ` mjt
-- strict thread matches above, loose matches on Subject: below --
2004-05-19 19:57 Burnes, James
2004-05-19 20:07 ` mjt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040524204751.GC4990@nysv.org \
--to=mjt@nysv.org \
--cc=Valdis.Kletnieks@vt.edu \
--cc=c-d.hailfinger.kernel.2004@gmx.net \
--cc=reiser@namesys.com \
--cc=reiserfs-list@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.