[Gnucash-changes] r13272 - gnucash/branches/cashutil - Halting the cashutil branch until further notice - development continues outside svn

[Josh Sled]

On Thu, 2006-02-16 at 01:10 +0000, Neil Williams wrote:
> On Thursday 16 February 2006 12:44 am, Josh Sled wrote:
> > On Thu, 2006-02-16 at 00:15 +0000, Neil Williams wrote:
> > > No-one here probably believes me, but IMHO it's actually easier to use
> > > CVS, makepatch and manifest files rather than svn merge. 
> >
> > I don't understand why you need to keep track of any more than 1 number
> > -- that of revision at which point you branched. 
> 
> That's the point, with my preferred system, I don't even have to do that. It's 
> the files that matter, not some arbitrary r number.

It's not arbitrary; the revision number reflects a particular version of
the state of the files.  You can "simplify" it to "[it's] the files that
matter", but you can't get away from the fact that that it is a
particular state of those files.


> Because I can't build and test cashutil if I haven't got the updated gnucash 
> objects and backend. Frankly, what on earth is the point of having an svn 
> branch if I don't have easy update access to the trunk?

Could you explain a bit more?  I don't understand why you need to merge
to get the updated gnucash objects and backend.

If you are not making conflicting changes, then the merge should be
trivial and easy... `svn merge -r «last merge id»:HEAD` ... and there
should never be a conflict or even manual intervention needed.  It
should basically be the equivalent to an `svn update`.  If you *are*
making conflicting changes, then it can't *possibly* be easier to work
out of tree: you'll still have the same conflicting code changes but
zero tool support for merging them together.  And it only gets worse
over time.

To ask another way: if you've branched a point T, you have two options:
either
- stick with the gnucash sources as of time T and develop cash util  
  against them, ignoring what's going on in the gnucash sources.
- track changes to the gnucash sources after time T.
By repeated merging, you seem to be trying to do the latter.  But moving
outside of the source tree seems to imply the former.  So, I'm confused
about how you're working with this branch that's making things hard.


And, no, the point of branching isn't to make access to trunk easier,
but instead to isolate changes; remember that 'trunk' is just the name
of a special branch.  If you should be developing against the trunk,
then you should.  I claim that cashutil should be developed against the
trunk.  It sounds like you're experiencing evidence that it should, as
well.


> > I think a CLI front-end is a valuable (future) addition to gnucash, and
> > I think cashutil should be part of the gnucash source tree ... in fact,
> > using the same translations and build system.  It's just another
> > front-end...  `./configure --enable-cli --disable-gtk` ... is it not?
> 
> No, it is not. It is separate, it deserves to be separate and more important 
> than anything else, despite it being in svn I'm the only one working on it 
> and I can no longer work within the svn branch.

Why not?

CashUtil seems to strive to be a command-line interface to the gnucash
engine, application-logic and backend. In the gnucash world, that's a
front-end.  Sure, we'll need to refactor a lot of the application logic
out over the next year to make a cli a real possibility.  Not to say
that what cashutil demonstrates now isn't nifty, but it's not really
going to be realized fully until some of those other changes happen.

In any case, I don't see how *anything* is made easier by working
outside of the source tree.

-- 
...jsled
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`