Using bzr with LaTeX

[Ramon Diaz-Uriarte]

On 12/15/06, John Arbash Meinel <john at arbash-meinel.com> wrote:
> Ramon Diaz-Uriarte wrote:
> > On 12/15/06, t u <towsonu2003 at gmail.com> wrote:
> >> Ramon Diaz-Uriarte wrote:
> >> >> b) bzr makes collaboration
> >> >> very simple; it is as simple as saying "I worked on the paper last
> >> >> night; grab my latest changes from the repository"; c) being bzr
> >> >> distributed I can, say, edit and work while commuting, keeping all the
> >> >> history in my laptop, and then sync with my coauthors' changes when I
> >> >> get to work.
> >>
> >> Hi,
> >>
> >> Thanks for the suggestions so far (and if you have any more, pls keep
> >> them coming :) they are great)
> >>
> >> The collaboration seemed interesting. Of course, not knowing anyone who
> >> uses linux + latex + bzr in non-virtual world (eh), collaboration with
> >> others is kinda hard.
> >>
> >> But it still seems doable. For example, I give a copy of my paper to my
> >> advisor, who makes corretions. It seems like I can than copy my bzr'd
> >> source to another directory, make the advisor's changes to the source,
> >> than merge the two if there are no conflicts.
> >>
> >
> > I am not sure why you'd want to copy your bzr there. If you and your
> > advisor are never editing at the same time, it is enough to just copy
> > your advisor-changed version on the directory where you have your
> > bzr-controlled sources.
> >
> > Otherwise (if you and your advisor can be making changes) then, yes,
> > your scheme seems reasonable. Something like:
> >
> > ~/my-version
> > bzr checkout my-version my-advisors-version
> >
> > and you edit under my-version, while incorporating your advisor's
> > changes under "my-advisors-version" directory, and then merge.
> >
> > But I am sure there are much smart approaches, and someone here will
> > suggest better ways.
>
> Well, for starters, if you are actually developing independently from
> your adviser you really want 'bzr branch' not 'bzr checkout'. Because
> 'bzr checkout' will keep the branches in sync.


Oooops, sorry. I screwed up here.


>
> Second, when I have done this sort of thing, I wasn't doing much work
> while my adviser reviewed it. So I would just stick with the same branch.
>
> >
> >
> >
> >> From the documentation[1], the commands look something like this:
> >> $ cd /path/to/mysource
> >> $ cd ../      # sorry for the redundancy
> >> $ bzr branch mysource advisorchanges
> >> do the changes
> >> $ cd mysource
> >> $ bzr diff -r branch:../advisorchanges
> >> $ bzr merge ../advisorchanges/
> >>
> >> Does this look about right?
> >>
>
> If you are doing that, you want to 'bzr commit' before you do the 'bzr
> diff' command.
>
> Also, I tend to just do the merge, and then review the diff, since it
> still hasn't been committed yet.
>
> So it is more:
>
> $ cd /path/to
> $ bzr branch mysource adviser
> # send adviser a copy of the text in adviser.
> # Any personal changes continue in 'mysource'.
> # Adviser has now sent back the changes.
> $ cd /path/to/adviser
> $ cp -f ~/from_adviser/paper.tex .
> $ bzr commit -m "Adivser's changes"
> $ cd ../mysource
> $ bzr merge ../adviser
> $ bzr st
> $ bzr diff | vim -
> $ bzr vimdiff # If you have the vimdiff plugin installed :)
> # Looks good
> $ bzr commit -m "merged adviser's changes"
> # Do more work
> $ cd /path/to/adviser
> $ bzr pull ../mysource # Overwrite with new text being sent to adviser
> # send this text to adviser... continue


Thanks! (This is a lot nicer than my workflow).


> >
> > Yes.
> >
> >> Also, do you use launchpad as your repository to sync your laptop and
> >> other computers?
> >>
>
> I use it for synchronizing my plugins, and some bzr branches. I don't
> generally host private stuff on Launchpad, since it is a public website.
> Usually with an Academic paper, or thesis, you would want to keep it
> private.
>
> >
> > Not really, and I don't think launchpad is supposed to be used for
> > that (though other people here really now a lot more than me).
> >
> > For most projects, we have a machine where all my groups stores stuff;
> > this is like a "centralized-type" approach. We checkout from there, we
> > commit there, and we update from there. For other things (say, my
> > .emacs, .bashrc, etc files), I just have one "central repo" in
> > whichever machine (e.g., the workstation at work). So note that with
> > these files I am just replicating, at a smaller scale, a "centralized
> > type" workflow; this is just because its the first I learned with
> > other VCS, and bzr also supports this style just fine. But there are
> > completely non-centralized workflows, and you might want to learn
> > about them, because they might be better for some situations.
> >
> > In general, if you have N machines, you can just use one as the
> > central repo, and still have N branches (i.e., you can have a branch
> > in the central machine, a branch that you have checked out from the
> > local machine), or else have N - 1 (all machines have checkout out,
> > except the central one). There are pros and cons to each.  I like the
> > idea of having a bunch of "equal status branches", and a central repo.
> > And that central repo can be (or not) on the same physical machine as
> > the "equal status branches".  But, as I said, I think there are more
> > "truly distributed workflows" that might adapt better to your needs.
> >
> >
> >> And 2 last questions:
> >> * how do you revert to an earlier revision (that is, you commited your
> >> 50th revision, and now you want to revert to your 5th revision)?
> >
> > Suppose you want to see how "mypaper.tex" looked at the 5th revision
> >
> > Do "bzr cat -r 5 mypaper.tex > mypaper.revision5.tex"
> >
> > (Of course, whether you call it "mypaper.revision5.tex" or anything
> > else is your choice).
> >
> > Now, you have "mypaper.tex" and "mypaper.revision5.tex". You can use
> > kdiff3 (which I heard about first in this email list, and is just a
> > fabulous tool), or whatever.
> >
> >
> > [One side comment: I find "bzr viz" extremely useful; it is part of
> > bzrtools. Easy to see what changed where and when].
>
> I tend to just do 'bzr revert -r 5 mypaper.tex'
>
> And then if I want to see the difference between 2 versions:
>
> bzr vimdiff -r 5 mypaper.tex # Diff from current back to revision 5
> bzr vimdiff -r 5..6 mypaper.tex # Difference between revision 6 and 5
>


Aha, I can see how this is a lot nicer than my approach a lot of the time.
However, is there something inherently wrong with
bzr cat -r 5 mypaper.tex > mypaper.revision5.tex?

I am asking because I've found the above less prone to mistakes if I
am working when I might need to interrupt my work suddenly and for a
while. For instance, while commuting or if my daughter wakes up from
her nap; with the cat to something, I can do that as often as I want,
and I do not need to remember what I did (or move up and see if I
reverted my version) so it is inocuous.

So, can I get into trouble from the above, or is it just that it is
not as efficient?



> But then I'm a Vim kind of guy. (And while I highly recommend it, I
> wouldn't recommend learning bzr, LaTeX and Vim all at the same time :)
>
> You can also get the 'difftools' plugin. Which allows you to specify an
> external diff tool. So you can do:
>
> bzr diff --using meld -r 5 mypaper.tex
>

(Also, you can do something similar with kdiff3.)


> My second favorite diff program is probably meld.
>

You mean, after emacs' ediff :-) (Just kidding; I use emacs for
editing, but for merging, etc, I often use kdiff3).


R.

> >
> >> * can you revert that (ie do above, than go back from your 5th revision
> >> to your 50th revision etc)?
> >
> > If you do the above, you are NOT changing your latest "mypaper.tex".
> > So, unless you directly edit/overwrite/etc mypaper.tex, there is no
> > need to undo anything.
> >
> >
> > That said, you can revert to a previous state, unrevert that, and this
> > will depend also on whether or not you have already commited your
> > changes. Take a look at the help for:
> > revert, shelve, unshelve, uncommit. (you can look at the help by
> > doint, e.g. "bzr help revert"). And notice that some of this might be
> > dangerous if not used carefully. (In contrast, the approach above of
> > creating a new file that contains a file from  a previous revision is
> > inocuous ---though, sure, it is very limited).
>
> To go back and forth could be as simple as:
>
> bzr revert -r 5 mypaper.tex
> bzr revert mypaper.tex # Revert back to tip.
>
> It is also possible to do:
>
> bzr branch -r 5 mysource mysource.at.5
>
> Just depending on what you need to do. I would guess the general use
> case is that you want to do some sort of "what did this used to look
> like, and what is it now" And I find either the difftools plugin, or the
> vimdiff plugin very useful for that.
>
> John
> =:->
>


-- 
Ramon Diaz-Uriarte
Statistical Computing Team
Structural Biology and Biocomputing Programme
Spanish National Cancer Centre (CNIO)
http://ligarto.org/rdiaz