Using bzr with LaTeX

[John Arbash Meinel]

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.

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

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

My second favorite diff program is probably meld.

> 
>> * 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
=:->