bzr
Terry Brown
while to straighten out pull vs merge vs update, but I
think I'm getting there and it's probably worth while.
It's not entirely clear why a lot of workflows suggest
a local mirror of the 'central' branch, which you then
branch again before making your own mods.
Obviously this is handy if you're offline, but other
than that, why not just merge the 'central' branch's
changes into your branch?
Anyway, my leo specific issue, which maybe existed
with CVS as well as bzr, comes from clones. So I've
modified icon handling code in leoEditCommands.py, and
saving LeoRefPy.leo propogates these changes into
leoProjects.txt which contains clones of nodes from
the icon implementation.
So... what? I have to merge leoProjects.txt into my
branch as well as leoEditCommands.py? Perhaps there's
no issue at all here, and I'll see that once I've
worked with it more. But it seems that (the changed
part of) leoProjects.txt is just a derived file, which
I usually try to avoid tracking in VCS.
Cheers -Terry
Ville M. Vainio
> It's not entirely clear why a lot of workflows suggest
> a local mirror of the 'central' branch, which you then
> branch again before making your own mods.
>
> Obviously this is handy if you're offline, but other
> than that, why not just merge the 'central' branch's
> changes into your branch?
It's just about the speed of the operations, I think. I just merge
from the central branch myself.
> So... what? I have to merge leoProjects.txt into my
> branch as well as leoEditCommands.py? Perhaps there's
> no issue at all here, and I'll see that once I've
> worked with it more. But it seems that (the changed
> part of) leoProjects.txt is just a derived file, which
> I usually try to avoid tracking in VCS.
Yeah, the derived files are not that good an idea in VCS (the doc/html
stuff should probably also be removed).
One solution is to never check in the derived files. I.e. when you do
your changes, just bzr revert the derived files.
--
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
Randy Kramer
> On Sun, Mar 2, 2008 at 7:56 PM, Terry Brown <terry_...@yahoo.com> wrote:
> > It's not entirely clear why a lot of workflows suggest
> > a local mirror of the 'central' branch, which you then
> > branch again before making your own mods.
> > Obviously this is handy if you're offline, but other
> > than that, why not just merge the 'central' branch's
> > changes into your branch?
> It's just about the speed of the operations, I think. I just merge
> from the central branch myself.
As a wannabee developer (initially hoping to make some improvements to nedit),
I anticipate keeping a local mirror of the central branch (of nedit, still
using CVS), so that I can experiment with my own changes.
I'd use my locally mirrored CVS to save my experimental changes (and allow me
to revert them, etc.) until I get to the point of having changes that are
appropriate to check in (or send patches) to the "real" (developer) CVS.
I know that one of the nedit developers has instructions on the nedit wiki
which suggest a local mirror, and, when asked, he said it was for essentially
that reason.
Randy Kramer
Ville M. Vainio
> As a wannabee developer (initially hoping to make some improvements to nedit),
> I anticipate keeping a local mirror of the central branch (of nedit, still
> using CVS), so that I can experiment with my own changes.
>
> I'd use my locally mirrored CVS to save my experimental changes (and allow me
> to revert them, etc.) until I get to the point of having changes that are
> appropriate to check in (or send patches) to the "real" (developer) CVS.
Obviously you should use something like bzr or hg for this, even if
you end up committing to cvs. One fun thing about these lightweight
VCS's is that it's very easy to set up a local repository (cd
mpyproject; bzr init; bzr add; bzr ci).
Edward K. Ream
Yeah, the derived files are not that good an idea in VCS (the doc/html
> So... what? I have to merge leoProjects.txt into my
> branch as well as leoEditCommands.py? Perhaps there's
> no issue at all here, and I'll see that once I've
> worked with it more. But it seems that (the changed
> part of) leoProjects.txt is just a derived file, which
> I usually try to avoid tracking in VCS.
stuff should probably also be removed).
My guess is that you are using the term "derived" file differently from Leo's standard usage, that is, a file derived from @file, @thin, etc. I am certainly open to removing the doc/html/*.html files from bzr control. They certainly are "derivative".
leoProjects.txt is yet another kind of "derivative" file in my way of thinking. Yes, I could remove it from bzr control, but that would mean that my notes would not be available until the official release. Perhaps that's not a bad idea: the bzr logs and diffs are more "primary" info.
Any more comments? I think this is an important discussion. Bzr is looking like a great tool, and it's great at least in part because there are so many ways to use it. So I'm willing to explore (over a period of weeks or even months) interesting ways to use it.
Edward
Kayvan A. Sylvan
> leoProjects.txt is yet another kind of "derivative" file in my way of
> thinking. Yes, I could remove it from bzr control, but that would mean that
> my notes would not be available until the official release. Perhaps that's
> not a bad idea: the bzr logs and diffs are more "primary" info.
No, I think it's a good idea to have the leoProjects.txt available (or
at least easy instructions for regenerating it from its source files).
---Kayvan
Terry Brown
I agree, leo's clones create something you probably don't see
elsewhere, sort of 'partially derived files'. The cost is that people
who want to have modified leoEditCommands.py on their branch must also
handle merges of leoProjects.txt, but this is a relatively small cost
vs. the benefits.
And maybe I misspoke when I said I'd avoid derived files in VCS, having
100% derived HTML docs. for example makes sense, why force the user to
generate them, particularly if they info. telling it how to do so are
in the docs. themselves :-)
Cheers -Terry
Randy Kramer
> Obviously you should use something like bzr or hg for this, even if
> you end up committing to cvs.
I've anticipated doing that, and spent some time looking at quite a few
alternatives to cvs, including things like git. (I skipped over hg--I had
some idea it wasn't free, and I don't recall coming across bzr before, I'll
look into it--your simple instructions in your next paragraph make it sound
easy ;-)
My most recent thoughts were to use CVS just so I got sort of thoroughly in
tune with (indoctrinated into), the various terms / usage scenarios that
others talk about--I'm not thoroughly comfortable with those at this point,
and starting in cvs *might be* worthwhile for that reason. (Oh, and iirc,
cvs and svn are currently the only things for which rpms exist for my
Mandriva2006 system, although I do want to upgrade my system in a few months
(and, obviously, if I'm going to develop, I can't be uncomfortable with
compiling things myself ;-)
> One fun thing about these lightweight
> VCS's is that it's very easy to set up a local repository
> (cd mpyproject; bzr init; bzr add; bzr ci).
Thanks!
Randy Kramer
Ville M. Vainio
> My most recent thoughts were to use CVS just so I got sort of thoroughly in
> tune with (indoctrinated into), the various terms / usage scenarios that
> others talk about--I'm not thoroughly comfortable with those at this point,
> and starting in cvs *might be* worthwhile for that reason. (Oh, and iirc,
Not really. You can use both bzr and hg exactly like cvs/svn if you
want, apart from the fact that they don't suck (well, svn doesn't
really suck). Think of "bzr merge" as "cvs update".
Don't even think of using CVS at this day and age, especially if you
have a choice.
Also, all of this should be quite easy:
http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html
> cvs and svn are currently the only things for which rpms exist for my
> Mandriva2006 system, although I do want to upgrade my system in a few months
> (and, obviously, if I'm going to develop, I can't be uncomfortable with
> compiling things myself ;-)
You don't necessarily need to compile - at least bzr is pure python,
while hg has some minimal parts (diff stuff) written in C.
Terry Brown
Randy Kramer <rhkr...@gmail.com> wrote:
> (Oh, and iirc,
> cvs and svn are currently the only things for which rpms exist for my
> Mandriva2006 system, although I do want to upgrade my system in a few
> months (and, obviously, if I'm going to develop, I can't be
> uncomfortable with compiling things myself ;-)
Two minor points. You missed a closing ')' ;-) and bzr is python, so
you can probably install just by 'python setup.py install' as root,
that's what I did.
Cheers -Terry
Edward K. Ream
Thanks for these thought. For now, at least, I'll leave bzr as it is.
Edward
Terry Brown
"Ville M. Vainio" <viva...@gmail.com> wrote:
> Think of "bzr merge" as "cvs update".
>
[snip]
>
> Also, all of this should be quite easy:
> http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html
I protest! :-) Bzr is cool, I'm glad leo's provided me with this
excuse to get into it, and it is definitely my VCS of choice now. But
it's not that simple. 'Think of "bzr merge" as "cvs update".' you
say... ok, so how do you think of "bzr update" then? I suspect bzr
started simple and then grew to include alternate workflows that more
exactly mimic other VCSs. So it's simple as long as you only learn
about one workflow and don't trip over the commands that belong to
other workflows.
I wonder if bzr would benefit from being able to set, as a branch level
attribute, the intended workflow, and then refused or at leased warned
when the user tries commands that typically belong to a different
workflow. I also wonder what this discussion is doing on
leo-e...@googlegroups.com :-)
Cheers -Terry
p.s. I (believe I) understand "bzr update", you don't have to add that
to this thread, unless you want to ;-)
Edward K. Ream
On Mon, 3 Mar 2008 21:04:07 +0200
> Think of "bzr merge" as "cvs update".[snip]
>
>I protest! :-)
> Also, all of this should be quite easy:
> http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html
I recently had a small Aha about Bzr. It was hidden in plain sight as captions to several diagrams in the tutorial. If you start with a bzr checkout, then bzr commits immediately affect the central repository. If you start with a bzr branch, commits only affect the local copy.
It's distinctions like this that made it harder for me to become comfortable with bzr than with cvs. But there is little reason to doubt that the transition to bzr will be A Good Thing.
Edward
thyrsus
by command line bzr implementation of the following workflow:
* I acquire a bzr "controlled" copy of the source.
* I make changes in a bzr compatible way.
* I propose the changes for "official" inclusion.
* Edward/The Leo Team accepts the changes into "official" Leo
(rejection must be by default: I don't trust my own code without a 2nd
pair of eyes; of course some out-of-band (e.g., Google groups)
explanation of the code's deficiencies is most welcome).
On Mar 4, 7:41 am, "Edward K. Ream" <edream...@gmail.com> wrote:
Ville M. Vainio
>
> I'm sorry to be so dense, but could someone give me the command line
> by command line bzr implementation of the following workflow:
>
> * I acquire a bzr "controlled" copy of the source.
>
> * I make changes in a bzr compatible way.
>
> * I propose the changes for "official" inclusion.
Busy now, gotta rush to work and can't give you the exact command, but
here it is (someone can expand):
go to launchpad, "register branch", go to branch page, see the push
url & command
bzr branch lp:leo-editor
cp -r leo-editor my-branch-name
cd my-branch-name
... hack hack hack...
execute the push command from above
send email
Terry Brown
"Ville M. Vainio" <viva...@gmail.com> wrote:
> go to launchpad, "register branch", go to branch page, see the push
> url & command
Hopefully once Ville gets to work he'll have time for a more detailed
response :-)
Below is a question I'd posed before which I'm hoping someone can
address re registering branches on launchpad.
Cheers -Terry
So Launchpad offers me Hosted, Mirrored, or Remote branches. So it
seems I could do:
1) Hosted: put stuff there and then check it out to my local machine
and have an unbound checkout locally that I periodically commit in
bound mode so all the local commits are mirrored onto the hosted branch.
2) Hosted: and just push stuff at it from my local branch as needed.
3) Mirrored: make my local branch visible to Launchpad somewhere.
Seems like (2) is the simplest. (1) has the advantage of preserving
all my commits, whereas (2) would only show accumulated changes at the
time of the push? But this isn't an issue really.
Does it sound like (2) is the right approach? Still getting used to
bazaar, appreciate all your comments on it so far.
Cheers -Terry
Ville M. Vainio
> Below is a question I'd posed before which I'm hoping someone can
> address re registering branches on launchpad.
I already answered this, but probably got spamfiltered. Just choose "hosted".