[texworks] Please help!

[Duncan Murdoch]

On 07/04/2014 3:24 PM, Marcin Borkowski wrote:
> Dnia 2014-04-07, o godz. 11:25:31
> Duncan Murdoch <murdoch.duncan at gmail.com> napisał(a):
>
> > Marcin mentioned Git and Mercurial.  I've never tried Mercurial; I
> > tried Git, and really hated it.  Subversion has a simpler model: one
> > central repository, every revision with a sequential revision number,
> > instead of every checked out copy having its own subset of revisions
> > from a not-so-well-defined cloud of revisions.  It's not easy to get
> > not-very-technical collaborators to use Subversion; Git was a
> > complete failure in this.
>
> Well, as I've written: Git is for the brave.  It is not by any means
> easy for a newcomer to the world of VCS.  Or a newcomer to the world of
> DVCSs, for that matter.  OTOH, Mercurial is much more newbie-friendly
> (I did test it on two people whose first contact with VCSs was Hg).
>
> And, what you describe as the advantage of SVN, is in fact its main
> weakness.  Nothing stops you from using a one-central-repo model in Hg
> or Git (in fact, I do this much of the time), but you are not *forced*
> to do that (like in SVN).  And the "cloud of revisions", as you call
> it, is not-so-well-defined only if your workflow is
> not-so-well-defined.  Also, why would SHAs be worse than revision
> numbers?
>
> Also, a *huge* disadvantage of SVN (and centralized VCSs in general) is
> that you have to be online to commit (or have your central repo
> locally, which may be not wise).  I often work while commuting, so SVN
> is unacceptable for me.
>
> I used RCS first (in one-person-only, small projects), then switched to
> Hg (and loved it), then read a few books/tutorials on Git and fell in
> love with it.  I guess that your problems with Git *may* come from the
> fact that it is radically different (and better) than most other
> systems (yes, including Mercurial).  (Disclaimer: I only read about SVN
> and did not actually use it, but I did read some comparisons.)
>
> One example: imagine the following use case.  You want to implement a
> feature X, but there are two ways to do it: X1 and X2.  You try X1; it
> sort of works, but then you try X2 and it's much better.  You want to
> discard X1 altogether, and implement X2 as a single commit, even though
> you actually implemented it in small steps.
>
> Now in Git, you can use branches and rebasing to achieve exactly this.
> Is anything like it possible in SVN?  (I don't know, I'm asking.)


This is pretty far off topic for this list, so I'll answer your 
question, then quit.

Branching is Subversion's weak point.   I believe the official way to do 
what you're saying is to create a branch from before X1 was committed, 
and spend a while working on it to implement X2, then finally merge all 
those changes back into the trunk.  Where this gets hard is if someone 
else is also committing changes to the trunk, because it's generally 
kind of painful to import those into your branch (I guess that's 
"rebasing") and if you don't, that final merge of X2 back into the trunk 
just gets harder and harder.

What I do instead is this:  get a working copy of the head with X1 in 
it.  Do a backwards merge to undo X1, and calculate a patch based on 
it.  Commit the patch somewhere else.  Now go through lots of steps to 
gradually implement X2, always recomputing the patch, and committing the 
changes, but never committing to the main project. (The patch file could 
be committed to it if you want to share your work, but I just commit it 
to a local repos.)

If other collaborators make changes to the main body of the program, 
then you need to update and recalculate (and save) your patch.  This way 
the base for your patch never gets too far from the head of the trunk.

Finally you've got it right; you apply the patch, and commit the main 
project.

Duncan Murdoch

>
> On a final note: the thing that actually made me want to switch from Hg
> to Git (even before I learned about its great features) was an
> excellent front-end to Git, called Magit.  But it's an Emacs
> application, so probably not very interesting to people on this list;).
>
> > Duncan  Murdoch
>
> Best,
>