Switching from CVS to Subversion: test svn repo available

classic Classic list List threaded Threaded
75 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Switching from CVS to Subversion: test svn repo available

Josh Sled
Recently we've been planning on moving the GnuCash repository from CVS to
Subversion. This week I've made the changes on cvs.gnucash.org to enable
anonymous and developer access to a subversion repository.  This encompases:

   - http-style anonymous access
   - svn+ssh authenticated developer access
   - setup of `viewcvs.cgi` for repository browsing
   - repository migration

NOTE that this setup, and especially the migrated repository, is ENTIRELY
PROVISIONAL.  While you can both checkout and (developers) commit changes,
we're going to THROW OUT this copy and do another, real, migration later.

The current idea is to do the changeover shortly after the gnome2-branch ->
HEAD collapse, which should occur in the next couple of weeks.


Repository Layout, Migration
----------------------------

Since svn doesn't have the same notions of modules, branches and tags that
CVS does, there's an initial decision to be made about the repository layout.
I've decided to use the "recommended" layout, described below.  As well, it
seems right that both 'gnucash' and 'gnucash-docs' are part of the same
repository.

The recommended layout has a `trunk` directory for main-line development,
with sibling `branches` and `tags` directories.  As such, the repository
looks like:

/repo/gnucash/trunk/AUTHORS
                   /README
                   /src
                   [...]
             /branches/gnucash-1-8-branch/AUTHORS
                                         /README
                                         /src
                                         [...]
                      /gnucash-gnome2-dev
                      [...]

             /tags/gnucash-1-8-11
                  /gnucash-1-8-10
                  [...]

     /gnucash-docs/trunk
                  /branches/[...]
                  /tags/[...]

If anyone thinks an alternative layout is better, please suggest it.  At DayJob
we reviewed the various styles last month and I this one does make the most
sense.


Migration Specifics and Decisions
---------------------------------

The cvs2svn migration script provides the option of running some
pattern-based conversions of the tag/branch names... we could, for instance,
drop the 'gnucash-' prefix and change '-' to '.', changing...

    /repo/gnucash/branches/gnucash-1-8-branch

...into...

    /repo/gnucash/branches/1.8

This is certainly more attractive, but all historical notions of tag-names in
people heads and out in the world would be invalidated.  Thoughts?


Another option is to only migrate a subset of the history; here I've migrated
it all, but we could easily only migrate -- say -- everything from 1.8 on:
1.8 branch (+tags), gnucash-gnome2-dev and HEAD.  As this migration didn't
take that long [*] without such a restriction and there's plenty of disk
space on svn.gnucash.org, it seems better to keep as much history as
possible.  Thoughts?

[*: For the curious, it look about 27 minutes to run cvs2svn to create a ~2GB
 dumpfile of the grouped-commits, and about 45 minutes to transact those
 changesets into the empty repository.]


One thing cvs2svn does /not/ provide (that I can see, anyways) is the
migration of the contents of the .cvsignore files into subversion's
'svn:ignore' directory-property.  Perhaps someone wants to cut their teeth on
subversion by doing this. :)



Introduction to Subversion
--------------------------

The excellent "Version Control with Subversion" [1] is a very good resource
for information about subversion.  Specifically, Chapter 3. Guided Tour [2]
and Appendix A. Subversion for CVS Users [3] are relevant.

The command-line client `svn` has a nice integrated help system; `svn help`
will provide the top-level command list, and `svn help <command>` detailed
help for the specific command.

[1] http://svnbook.red-bean.com/
[2] http://svnbook.red-bean.com/en/1.1/ch03.html
[3] http://svnbook.red-bean.com/en/1.1/apa.html


The command-line svn client is intentionally similar to the cvs client, with
some important differences; here's a brief mapping of the commands:

cvs checkout        -> svn checkout
cvs commit          -> svn commit
cvs status          -> svn status [...but one that's actually useful :)]
cvs log             -> svn log
cvs annotate        -> svn blame
cvs diff            -> svn diff
cvs update          -> svn update, svn switch
cvs update -C       -> svn revert
cvs update -j [...] -> svn merge
   ----             -> svn resolved [conflicting merges must be explicitly resolved]
cvs add             -> svn add, svn mkdir
cvs remove          -> svn delete
   ----             -> svn move
cvs [r]tag [-b]     -> svn copy


Repository Addresses
--------------------

svn.gnucash.org is setup and resolves (thanks Linas! :), so the various base
URLs look like:

  anonymous:  http://svn.gnucash.org/repo/gnucash/trunk 
  developer:  svn+ssh://svn.gnucash.org/repo/gnucash/trunk
    viewcvs:  http://svn.gnucash.org/cgi-bin/viewcvs.cgi

As in...

    $ svn checkout http://svn.gnucash.org/repo/gnucash/trunk gnucash

    $ svn switch http://svn.gnucash.org/repo/gnucash/branches/gnucash-gnome2-dev

    $ svn copy svn+ssh://svn.gnucash.org/repo/gnucash/trunk \
          svn+ssh://svn.gnucash.org/repo/gnucash/branches/big-nasty-change


commit mails
------------

I've setup the post-commit hook to mail the changeset diffs to
'[hidden email]'.  Note that a seperate gnucash-patches mail of
only the commit notice (without diffs) is *not* setup here.  I'm not sure that
it will be, either.  If you have a strong desire to have a
non-diff-containing-per-commit email, speak up now.


viewcvs.cgi
-----------

cvsweb does not support subversion, and apparently will not; viewcvs does and
has been installed at http://svn.gnucash.org/cgi-bin/viewcvs.cgi/ .


Feedback
--------

PLEASE checkout and play around with this provisional repository.  If you're
a dev, then PLEASE make some changes and check them in.  Try to explore the
history to make sure it's all there.  Create a branch, rename some files, &c.

Please let me (and the list) know if there are any configuration issues or
problems.  I'll be traveling next week, but will be checking mail
periodically and certainly when I get back.


...jsled
--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

Chris Shoemaker
I tried to view a diff and got this:

An Exception Has Occurred
Python Traceback

Traceback (most recent call last):
  File "/usr/lib/viewcvs-1.0/lib/viewcvs.py", line 3362, in main
    request.run_viewcvs()
  File "/usr/lib/viewcvs-1.0/lib/viewcvs.py", line 379, in run_viewcvs
    self.view_func(self)
  File "/usr/lib/viewcvs-1.0/lib/viewcvs.py", line 2800, in view_revision
    date, author, msg, changes = vclib.svn.get_revision_info(request.repos)
  File "/usr/lib/viewcvs-1.0/lib/vclib/svn/__init__.py", line 255, in get_revision_info
    svnrepos.pool)
  File "/usr/lib/viewcvs-1.0/lib/vclib/svn/__init__.py", line 93, in _datestr_to_date
    return core.svn_time_from_cstring(datestr, pool) / 1000000
SubversionException: (None, 125003)

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

Josh Sled
On Sat, 2005-10-22 at 18:50 -0400, Chris Shoemaker wrote:
> I tried to view a diff and got this:

Hmm, I read comments mentioning something like this, but didn't see it
myself.  Admittedly, I didn't test too much.

In the last released viewcvs (0.9.4), the subversion support seems to be
broken.  This version is from their CVS HEAD, which does basically work
w.r.t. subversion, but apparently has some diff issue.

...jsled
--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

Conrad Canterford
In reply to this post by Josh Sled

Generally, I'm happy with the proposed changes, and personally, I don't
see anything wrong with invalidating the old names, especially as we're
getting close to doing a new release branch anyway. The proposed
structure looks fine to me. Of course, since I'm not doing any active
development, none of this is really my call, but there's my comments
anyway.

However, I do prefer the non-diff'd emails in gnucash-patches. Since I
am not actively developing, I really don't get any value from seeing the
diffs, but I do track development by reading the log comments (yes, they
do get read!). If I'm the only one who thinks them useful, I will put up
with the bigger emails, but I'd much prefer not to have to.

Conrad.

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

Chris Shoemaker
In reply to this post by Josh Sled
        SVN is clearly superior to CVS.  SVN basically seems like a
faster, less-annoying, more-featureful version of CVS.  But, like CVS, it
was never intended to be a SCM system [1], it's just a version control
system.  Since we're obviously writing software, I think a real SCM
has compelling advantages.  So, I'd like everybody to also consider
some other SCMs, especially of the distributed variety.

        Here are a few reasons why:

** Changesets **
        SVN perpetuates what is, in my opinion, a horrible disease
instituted by CVS: the idea that users care about FILE history, but
not PROJECT history.  Its model is: the repository is a collection of
files that have version history.  (I realize they can be renamed.)

        Alternatively, for another breed of SCMs the model is: the
repository is a project that has history, which happens to be
represented by files.  This distinction may (or may not?) seem subtle
but it is HUGE.  This is the whole concept of
changesets/patchsets/commits-whatever.  It lets the user view and
operate atomically on "changesets" that affect many files.  This is
*SO* useful, that once you're used to it, not being able to do it just
seems like wandering around in the dark with you hands tied behind
your back.  
        [ SCMs that implement this concept include tla (aka arch),
darcs, bitkeeper, cogito, mecurial, and others. ]

** Centralized vs. Distributed **
        SVN is centralized.  I know SVN+SVK is distributed.  But, I
want to make the case that distributed is not "gravy" but an important
feature.  Then we can evaluate SVN+SVK alongside other distributed
systems.
        IMO, the reason distributed SCM is important boils down to
"fringe" developer convenience.  I grant that, for core-developers,
distributed SCM *may* not offer compelling advantages, but for
"fringe" developers distributed SCM offers substantial benefit.
        Who are those fringe developers?  The casual patch submitter,
the aspiring core developer, and the occasional on again, off again,
developer, etc.
        What are those benefits?  Easier to share/review code while
maintaining full incremental history of development.  Smaller
contribution hunks, since the "commits" are made at development time,
to someone's local tree.  That, in turn, means better log
descriptions.  Easier maintenance of experimental branches: Because:
 
          *** Distributed SCM allows even "fringe" developers
              to have the benefits of a full-blown SCM. ***

        Why should the core developers care?  Because some "fringe"
developers may become core developers, and Gnucash needs more
developers.

** Logging **
        Logging is important enough to do well.  Keeping two sets of
logs, commit-time logs, plus ChangeLog file, is difficult,
less-useful, and error-prone.  With CVS it was a necessary evil, since
at very minimum, it's important to associate related changes in
multiple files.  (It seems this problem would remain with SVN.)
        A good SCM keeps commit logs sufficient for logging both the
file histories and the project history.  Then, the "ChangeLog" comes
directly out of the SCM and contains exactly the information that it
should, and it's automatically correct.

** Summary **
        In summary, I think there are two main reasons for looking
further than SVN for SCM software.  1) Changesets are a big
convenience for all developers.  2) Distributed SCM lets fringe
developers benefit from a real SCM, too.

-chris

[1] http://svnbook.red-bean.com/en/1.1/ch01.html#svn-ch-1-sect-1

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

Stuart D. Gathman
On Sun, 23 Oct 2005, Chris Shoemaker wrote:

>         Alternatively, for another breed of SCMs the model is: the
> repository is a project that has history, which happens to be
> represented by files.  This distinction may (or may not?) seem subtle
> but it is HUGE.  This is the whole concept of
> changesets/patchsets/commits-whatever.  It lets the user view and
> operate atomically on "changesets" that affect many files.  This is
> *SO* useful, that once you're used to it, not being able to do it just
> seems like wandering around in the dark with you hands tied behind
> your back.  

I thought this was the main point of SVN, and the motivation for
replacing CVS - that it has atomic changesets that affect many files.

--
              Stuart D. Gathman <[hidden email]>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

Chris Shoemaker
On Sun, Oct 23, 2005 at 07:09:36PM -0400, Stuart D. Gathman wrote:

> On Sun, 23 Oct 2005, Chris Shoemaker wrote:
>
> >         Alternatively, for another breed of SCMs the model is: the
> > repository is a project that has history, which happens to be
> > represented by files.  This distinction may (or may not?) seem subtle
> > but it is HUGE.  This is the whole concept of
> > changesets/patchsets/commits-whatever.  It lets the user view and
> > operate atomically on "changesets" that affect many files.  This is
> > *SO* useful, that once you're used to it, not being able to do it just
> > seems like wandering around in the dark with you hands tied behind
> > your back.  
>
> I thought this was the main point of SVN, and the motivation for
> replacing CVS - that it has atomic changesets that affect many files.

Please see: http://subversion.tigris.org/faq.html#changesets

for a rather biased, but not unhelpful answer.  The frank answer is
that there's a *fundamental* *architectural* difference between
designs that use arrays of versioned trees and designs that use DAGs
of changesets.  I would dispute the "neither philosophy is better"
part.

FWIW, my take on the status of this debate is that it's basically
over.  The systems using changesets have proven far more useful, and
made the versioned-trees approach seem ... well... backward.

But, there are those who feel far more strongly, and are far better
informed than I, who make the case far better that I could.  I'd
suggest googling around and reading the rantings of some of the
designers of changeset-based systems, if you're interested in the
debate.

Here's a fun link to git's author's opinion on the matter:
http://www.gelato.unsw.edu.au/archives/git/0504/0594.html

I'm sure dredging LKML for BK flamefests would turn up similarly fun
stuff.

Have fun!

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

Fabien COELHO
In reply to this post by Chris Shoemaker

Dear Chris,

> ** Changesets **
> ** Centralized vs. Distributed **
>        In summary, I think there are two main reasons for looking
> further than SVN for SCM software.  1) Changesets are a big
> convenience for all developers.  2) Distributed SCM lets fringe
> developers benefit from a real SCM, too.

I must first state that I'm biased towards SVN. Nevertheless:

The actual question you should ask is "what is a desirable development
model for gnucash", and then chose the best tool to support that model.
Best is about features / support / stability / easy to understand /
free / available / portable...

If you're in a war zone with many developpers where everybody wants to
develop its "own" personnal version and no one can fully agree on
something common (say you're in the linux kernel;-) then changesets and a
distributed approach is the (only) way to handle the anarchy;-)

If you want to produce "one" stable software with a close collaboration
between (few) developers, then the centralized solution looks much better
to keep control of what is going on. I agree that changesets are better
than simple file histories, but svn provides a reasonnable approximation.
ISTM that subversion's 'fsfs' backend does store changesets internally, by
the way.

So I think that svn as a better cvs is a good move for *gnucash*, although
it may not necessarily be the case for other softwares with different
aims and cultures.

--
Fabien COELHO   _____   [hidden email]   _____   http://www.coelho.net
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

Chris Shoemaker
On Mon, Oct 24, 2005 at 03:37:52PM +0200, Fabien COELHO wrote:

>
> Dear Chris,
>
> >** Changesets **
> >** Centralized vs. Distributed **
> >       In summary, I think there are two main reasons for looking
> >further than SVN for SCM software.  1) Changesets are a big
> >convenience for all developers.  2) Distributed SCM lets fringe
> >developers benefit from a real SCM, too.
>
> I must first state that I'm biased towards SVN. Nevertheless:
>
> The actual question you should ask is "what is a desirable development
> model for gnucash", and then chose the best tool to support that model.
> Best is about features / support / stability / easy to understand /
> free / available / portable...

I agree with this approach.

>
> If you're in a war zone with many developpers where everybody wants to
> develop its "own" personnal version and no one can fully agree on
> something common (say you're in the linux kernel;-) then changesets and a
> distributed approach is the (only) way to handle the anarchy;-)
>
> If you want to produce "one" stable software with a close collaboration
> between (few) developers, then the centralized solution looks much better
> to keep control of what is going on.

The actual state of things is that there are *very* few developers,
and I think the survival of gnucash depends on attracting more.  That
doesn't necessarily require a distributed model, but I think one key
step is providing the convenience of SCM to "fringe" developers.  That
could still happen in a centralized model, for example, if an
automated webform granted permission to create new branches and commit
to them so that all devs can see the newly developed code and provide
guidance long before it would be time for a patchbomb.  And if it was
very easy to keep dev branches in sync with main branch.

My point is not so much "distributed is better than centralized", as
it is "lower the barriers to new developers by letting them share code
early and often."  Distributed SCM is *one* way to do that.

> I agree that changesets are better
> than simple file histories, but svn provides a reasonnable approximation.

It *is* a reasonable approximation, *for certain purposes*.  But,
branch-merging is not one of those purposes, which is what makes it
easy to keep parallel dev branches in sync.

> ISTM that subversion's 'fsfs' backend does store changesets internally, by
> the way.
>
> So I think that svn as a better cvs is a good move for *gnucash*, although
> it may not necessarily be the case for other softwares with different
> aims and cultures.

Thanks for your thoughtful reply.

-chris

>
> --
> Fabien COELHO   _____   [hidden email]   _____   http://www.coelho.net
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

Stuart D. Gathman
In reply to this post by Chris Shoemaker
On Sun, 23 Oct 2005, Chris Shoemaker wrote:

> > I thought this was the main point of SVN, and the motivation for
> > replacing CVS - that it has atomic changesets that affect many files.
>
> Please see: http://subversion.tigris.org/faq.html#changesets
>
> for a rather biased, but not unhelpful answer.  The frank answer is
> that there's a *fundamental* *architectural* difference between
> designs that use arrays of versioned trees and designs that use DAGs
> of changesets.  I would dispute the "neither philosophy is better"
> part.

Thanks.  That was very helpful.  So SVN does have atomic commits
that affect multiple files - unlike CVS.  But it internally stores versioned
trees of file collections vs versioned trees of files for CVS vs
collections of patches for changeset based systems.

> FWIW, my take on the status of this debate is that it's basically
> over.  The systems using changesets have proven far more useful, and
> made the versioned-trees approach seem ... well... backward.

A very important feature for me is that the repository format stills allows
me to extract the latest version of things if it gets corrupted.  I'm
not sure SVN meets that criterion, but CVS does.  That was the main
motivation for us moving from SCCS to RCS before CVS came out.

> But, there are those who feel far more strongly, and are far better
> informed than I, who make the case far better that I could.  I'd
> suggest googling around and reading the rantings of some of the
> designers of changeset-based systems, if you're interested in the
> debate.

I can easily see how certain operations would be quicker and more
natural for a changeset system.  But there are many criterion, and
I suspect said rantings reflect different priorities than mine.

> Here's a fun link to git's author's opinion on the matter:
> http://www.gelato.unsw.edu.au/archives/git/0504/0594.html

The main point here is that per file tracking is wrong - and I would
agree.  Maybe I'm missing something, but from what I have read, SVN
stores version trees of filesets rather than files - that is its motivation for
replacing CVS.  Sure, it is storing version trees of the fileset rather
than a collection of changesets for the fileset, but the above rant doesn't
seem to apply to SVN.

--
              Stuart D. Gathman <[hidden email]>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

Brian-5
In reply to this post by Chris Shoemaker
On Mon, 2005-24-10 at 10:53 -0400, Chris Shoemaker wrote:

> The actual state of things is that there are *very* few developers,
> and I think the survival of gnucash depends on attracting more.  That
> doesn't necessarily require a distributed model, but I think one key
> step is providing the convenience of SCM to "fringe" developers.  That
> could still happen in a centralized model, for example, if an
> automated webform granted permission to create new branches and commit
> to them so that all devs can see the newly developed code and provide
> guidance long before it would be time for a patchbomb.  And if it was
> very easy to keep dev branches in sync with main branch.
>
> My point is not so much "distributed is better than centralized", as
> it is "lower the barriers to new developers by letting them share code
> early and often."  Distributed SCM is *one* way to do that.

I agree with with Chris on this one.  I am not much of a developer, but
would like to contribute when I can.  Several months back I tried making
changes to make the hard coded business info in the fancy-invoice
dynamic.  I was able to extend the File=>Properties dialog and get the
additional data saved and reloaded, but could not get the fancy-invoice
to retreive that data.  (Yes I exported it, I'm with Neil about
Scheme :( )
It would probably have only taken someone else 5-10 minutes to fix it.
Unfortunately I got too busy to keep plugging away at it and it has now
missed the final 1.8 release.

I am probably not the only one that could contribute code that way.

Another compelling reason:  Just look at several of the recent threads
complaining about changes breaking things and others not knowing what
others are in the process of changing.  SVN will help, but may not be as
good.


--
Brian <[hidden email]>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

Derek Atkins
Quoting Brian <[hidden email]>:

>> My point is not so much "distributed is better than centralized", as
>> it is "lower the barriers to new developers by letting them share code
>> early and often."  Distributed SCM is *one* way to do that.
>
> I agree with with Chris on this one.  I am not much of a developer, but
> would like to contribute when I can.  Several months back I tried making
> changes to make the hard coded business info in the fancy-invoice
> dynamic.  I was able to extend the File=>Properties dialog and get the
> additional data saved and reloaded, but could not get the fancy-invoice
> to retreive that data.  (Yes I exported it, I'm with Neil about
> Scheme :( )
> It would probably have only taken someone else 5-10 minutes to fix it.
> Unfortunately I got too busy to keep plugging away at it and it has now
> missed the final 1.8 release.
>
> I am probably not the only one that could contribute code that way.

And what stopped you from doing, effectively:

  cvs -q diff -u | mail [hidden email]

There's nothing that was stopping you from doing this, as far as I can
tell.  A
different SCM would have just changed the commandline you used.

The problem here is not the tools available.  It's individual workhabits.

> Another compelling reason:  Just look at several of the recent threads
> complaining about changes breaking things and others not knowing what
> others are in the process of changing.  SVN will help, but may not be as
> good.

SVN would have helped.
Using CVS Branches would have helped.
Committing working code would have been best ;)  But neither CVS nor SVN can
help  there.  ;)

A tool is still a tool.  It doesn't reduce the work involved in writing good
code.

The problem is that historically the commiters have been restricted to
a trusted
group of people, but there are a few "new" developers who have not yet been
given commit access.  Honestly I can only think of one developer in
particular.

GnuCash handles people's money!  People need to be able to trust the
code.  This
means limited commit access and gatewaying of patches.  it also means
using the
tools we have appropriately.  Neil should not have been using the g2 branch to
do the QOF work; there should have been a new branch for that.

A distributed SCM makes no sense for gnucash.  There just aren't enough
developers, and the code base just isn't that large.  It's still perfectly
reasonable to be shipping patches around.

If you really want a distributed SCM, consider SVK.

-derek

PS: Every Software Engineer should know scheme.  They don't have to
like it. They don't have to be proficient in it.  But they should know
it.  The
historical significance of Lisp/Scheme to the development Computer Science
alone  should be sufficient to expose you to the language.  I'll note
that I've
never liked Scheme myself, but I at least understand why it was created.

PPS: Scheme is so easy to learn that if you can't learn the _syntax_ in a day
you should hang up your keyboard and find another profession.  Learning the
available functions/procedures can certainly take longer, but the MIT Scheme
Reference is extremely handy.

http://www.swiss.ai.mit.edu/projects/scheme/documentation/scheme.html

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

Chris Shoemaker
In reply to this post by Stuart D. Gathman
On Mon, Oct 24, 2005 at 12:38:35PM -0400, Stuart D. Gathman wrote:

> On Sun, 23 Oct 2005, Chris Shoemaker wrote:
>
> > > I thought this was the main point of SVN, and the motivation for
> > > replacing CVS - that it has atomic changesets that affect many files.
> >
> > Please see: http://subversion.tigris.org/faq.html#changesets
> >
> > for a rather biased, but not unhelpful answer.  The frank answer is
> > that there's a *fundamental* *architectural* difference between
> > designs that use arrays of versioned trees and designs that use DAGs
> > of changesets.  I would dispute the "neither philosophy is better"
> > part.
>
> Thanks.  That was very helpful.  So SVN does have atomic commits
> that affect multiple files - unlike CVS.  But it internally stores versioned
> trees of file collections vs versioned trees of files for CVS vs
> collections of patches for changeset based systems.

If you'd like some more detailed info, I'd recommend:
[5] for the heart of the issue in concise terms
[6] for an good overview of the main SCM debate
[8] for an overview of SCM softwares available
[1, 2, 7] for some informative Arch vs. SVN debate
[3] for a practical perspective on SCM usage

[1] http://www.reverberate.org/computers/ArchAndSVN.html
[2] http://web.mit.edu/ghudson/thoughts/undiagnosing
[3] http://www.kdedevelopers.org/node/1028
[4] http://subversion.tigris.org/faq.html#changesets
[5] http://sourcefrog.net/weblog/software/vc/derivatives.html
[6] http://www.dwheeler.com/essays/scm.html
[7] http://web.mit.edu/ghudson/thoughts/diagnosing 
[8] http://linuxmafia.com/faq/Apps/scm.html 

>
> > FWIW, my take on the status of this debate is that it's basically
> > over.  The systems using changesets have proven far more useful, and
> > made the versioned-trees approach seem ... well... backward.
>
> A very important feature for me is that the repository format stills allows
> me to extract the latest version of things if it gets corrupted.  I'm
> not sure SVN meets that criterion, but CVS does.  That was the main
> motivation for us moving from SCCS to RCS before CVS came out.

before CVS came out?!  You've .. um... been around a while, eh?  :)

>
> > But, there are those who feel far more strongly, and are far better
> > informed than I, who make the case far better that I could.  I'd
> > suggest googling around and reading the rantings of some of the
> > designers of changeset-based systems, if you're interested in the
> > debate.
>
> I can easily see how certain operations would be quicker and more
> natural for a changeset system.  But there are many criterion, and
> I suspect said rantings reflect different priorities than mine.
>
> > Here's a fun link to git's author's opinion on the matter:
> > http://www.gelato.unsw.edu.au/archives/git/0504/0594.html
>
> The main point here is that per file tracking is wrong - and I would
> agree.  Maybe I'm missing something, but from what I have read, SVN
> stores version trees of filesets rather than files - that is its motivation for
> replacing CVS.  Sure, it is storing version trees of the fileset rather
> than a collection of changesets for the fileset, but the above rant doesn't
> seem to apply to SVN.

You might agree or disagree with the premise but the rant *certainly*
applies to SVN.  The links above will explain.

-chris

>
> --
>      Stuart D. Gathman <[hidden email]>
>     Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
> "Confutatis maledictis, flamis acribus addictis" - background song for
> a Microsoft sponsored "Where do you want to go from here?" commercial.
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

Derek Atkins
Quoting Chris Shoemaker <[hidden email]>:

>> A very important feature for me is that the repository format stills allows
>> me to extract the latest version of things if it gets corrupted.  I'm
>> not sure SVN meets that criterion, but CVS does.  That was the main
>> motivation for us moving from SCCS to RCS before CVS came out.
>
> before CVS came out?!  You've .. um... been around a while, eh?  :)

How young ARE you?  Even /I/ remember the time before CVS.

-derek

PS: I don't need to google.  I very well understand different SCMs and I very
much understand the differences between something like SVN and something like
Bitkeeper.  I still think your arguments are irrelevant for the gnucash
project, and all you're doing is wasting time, bandwidth, and meritocracy
points.
--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

Chris Shoemaker
In reply to this post by Derek Atkins
On Mon, Oct 24, 2005 at 01:20:11PM -0400, Derek Atkins wrote:
> The problem is that historically the commiters have been restricted
> to a trusted group of people,

I disagree that that's the problem, but, assuming you're
right... How's that strategy been working for GnuCash over the past 3
years?

> but there are a few "new" developers who have not yet been
> given commit access.  Honestly I can only think of one developer in
> particular.

        I suppose you mean me.  You know, I've been devoting quite a
bit of thought to the survivability of Gnucash recently and especially
on attracting new developers.  I'm still mulling over bits, but I have
concluded at least one thing: Giving one more person commit access
WON'T FIX THE PROBLEM.  I'm sure of it.

        I've been trying to answer the question: why aren't there more
developers hacking Gnucash.  Until recently, I found the "codebase
complexity" answer somewhat convincing.

        Interestingly, the installation of gitweb has changed my
perspective of this issue.  (Check it out, it's facinating:
http://www.codesifter.com/cgi-bin/gitweb.cgi)

        What I didn't really appreciate is that there are many more
casual developers submitting patches than I realized.  E.g: Scott
Oonk, Didier Vital, Ed Huff, Frederic Leroy, Dan Widyono, Geert Jan
Jansens, Bill Nottingham, Stephen Evanchik, Paul Kronenwetter, Matthew
Vanecek, Vitaly Lipatov, Heath Martin, Darin Willits, Pritt Laes,
Christian Neumair, Tomas Cernaj, Yves-Eric Martin, Todd Fries, Thomas
Bushnell, David Montenegro, John Ellson, Rich Johnson, James
Strandboge, Phil Longstaff, and many more.

        There are changes from more than 20 people in the recent past,
just for the G2 branch!  These aren't just trivial one-liners, many of
these people are hacking "deep" parts of gnucash, (register, reports,
modules, GUI, etc.) and submitting patches.  But there are some
disturbing patterns.

        For the most part, the contributions don't last very long.
Why?  I can't say it's code complexity, because they've already
grokked the code enough to improve it.  Then why?  I correlated the
patch commits to mailing list entries.  Guess what?  THESE FRINGE
DEVELOPERS ARE PRACTICALLY IGNORED.  Their patches take weeks, months,
or even almost a year to apply, often with no comment or feedback save
perhaps "applied".  This is disrespectful, abusive and, most
importantly, DISFUNCTIONAL.  And it could be one reason why they don't
send more patches.

        It's also clear from the commit and mailing list history that
this problem is getting WORSE with time.  Believe me, giving me commit
access WILL NOT SOLVE THIS PROBLEM.  (Although it would make *my*
development easier.)  

        But, there are solutions, and I'm forming some opinions on
what they might be.  But, I'd REALLY like to hear waht some of these
"fringe" developers think would make them contribute more time and
effort to Gnucash developement.  So, SPEAK UP!!!


> GnuCash handles people's money!  People need to be able to trust the
> code.  This
> means limited commit access and gatewaying of patches.  

There's something that doesn't sound quite right about this, but I'll
think about it for a while.  

For now, I'll just point out that limited commit access does not
preclude even the most distributed developement model or widest commit
access.  In a fully-distributed model (which I'm not necessarily
advocating) commit access is infinitely restricted.  No one can ever
commit to any repository but their own.  All code-sharing is done by
"pulling" code.  You can be the one-and-only gatekeeper of all patches
to your repository.

Furthermore, even using a centralized SCM, letting new developers use
the SCM doesn't necessarily mean "violating security protocol by
allowing unwashed masses to touch the OneTrueBuild."

> it also means
> using the
> tools we have appropriately.  Neil should not have been using the g2 branch
> to
> do the QOF work; there should have been a new branch for that.
>
> A distributed SCM makes no sense for gnucash.  There just aren't enough
> developers, and the code base just isn't that large.  It's still perfectly
> reasonable to be shipping patches around.
>
> If you really want a distributed SCM, consider SVK.

I'm looking into it, but it sure doesn't stack up well compared to
other options.  :(

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

Chris Shoemaker
In reply to this post by Derek Atkins
On Mon, Oct 24, 2005 at 02:02:51PM -0400, Derek Atkins wrote:

> Quoting Chris Shoemaker <[hidden email]>:
>
> >>A very important feature for me is that the repository format stills
> >>allows
> >>me to extract the latest version of things if it gets corrupted.  I'm
> >>not sure SVN meets that criterion, but CVS does.  That was the main
> >>motivation for us moving from SCCS to RCS before CVS came out.
> >
> >before CVS came out?!  You've .. um... been around a while, eh?  :)
>
> How young ARE you?  Even /I/ remember the time before CVS.

:) Too young to have been worrying about version control software in
1986.  (or was it earlier?)

> -derek
>
> PS: I don't need to google.  I very well understand different SCMs and I
> very
> much understand the differences between something like SVN and something
> like
> Bitkeeper.  I still think your arguments are irrelevant for the gnucash
> project, and all you're doing is wasting time, bandwidth, and meritocracy
> points.

That's a bit dismissive don't you think?  :( You probably don't mean
to sound like an arrogant elitist, but it does sort of come across
that way.  It kind of makes me want to respond like others have [1],
but I want to remain constructive.

-chris

[1] http://lists.gnucash.org/pipermail/gnucash-devel/2001-July/004343.html


> --
>       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>       Member, MIT Student Information Processing Board  (SIPB)
>       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>       [hidden email]                        PGP key available
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

David Hampton-2
On Mon, 2005-10-24 at 14:52 -0400, Chris Shoemaker wrote:

> It kind of makes me want to respond like others have [1],
> but I want to remain constructive.

If you wanted to remain constructive you wouldn't have posted that URL.

David


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

Stuart D. Gathman
In reply to this post by Chris Shoemaker
On Mon, 24 Oct 2005, Chris Shoemaker wrote:

> > > Here's a fun link to git's author's opinion on the matter:
> > > http://www.gelato.unsw.edu.au/archives/git/0504/0594.html
> >
> > The main point here is that per file tracking is wrong - and I would
> > agree.  Maybe I'm missing something, but from what I have read, SVN
> > stores version trees of filesets rather than files - that is its motivation for
> > replacing CVS.  Sure, it is storing version trees of the fileset rather
> > than a collection of changesets for the fileset, but the above rant doesn't
> > seem to apply to SVN.
>
> You might agree or disagree with the premise but the rant *certainly*
> applies to SVN.  The links above will explain.

I'm sorry, I must be dense.  I reread the rant, and it is all
about "the single-file mentality is a disease".  I read more of
the links about SVN, and it certainly doesn't have a
"single-file" mentality as I understand it.  It operates atomically on an
entire repository.  It atomically applies a changeset - eventhough
it actually updates (atomically) the repository and recomputes
the changeset when requested, rather than storing the changeset and
recomputing the files when requested as you advocate.

Now perhaps "single-file mentality" means something more than its
face value.  For instance, perhaps the "file" being referred to
is a repository rather than a source file, and the rant against "single-file
mentality" is really a rant against a centralized server - which SVN certainly
is.  Am I on the right track here?  Is the objection to SVN that it is
centralized, and there is a "single-file" (plus backups) that represents a
repository instead of multiple "files" distributed over the internet?

The distributed vision seems to be that loosely connected sites collect
changesets, and a release is constructed on any one of those systems by
specifying a particular selection of changesets (the ones that produced
a particular working directory, for instance) and giving it a release
version number.

--
              Stuart D. Gathman <[hidden email]>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

David Hampton-2
In reply to this post by Chris Shoemaker
On Mon, 2005-10-24 at 13:42 -0400, Chris Shoemaker wrote:

> If you'd like some more detailed info, I'd recommend:
> [5] for the heart of the issue in concise terms
> [6] for an good overview of the main SCM debate
> [8] for an overview of SCM softwares available
> [1, 2, 7] for some informative Arch vs. SVN debate
> [3] for a practical perspective on SCM usage
>
> [1] http://www.reverberate.org/computers/ArchAndSVN.html
> [2] http://web.mit.edu/ghudson/thoughts/undiagnosing
> [3] http://www.kdedevelopers.org/node/1028
> [4] http://subversion.tigris.org/faq.html#changesets
> [5] http://sourcefrog.net/weblog/software/vc/derivatives.html
> [6] http://www.dwheeler.com/essays/scm.html
> [7] http://web.mit.edu/ghudson/thoughts/diagnosing 
> [8] http://linuxmafia.com/faq/Apps/scm.html 

I've read through a bunch of these postings and I remain unconvinced
that one is better than the other.  I agree with [5] that this is solely
a discussion of the format in which changes are maintained; that there
is no difference in content.  I can where there might be some advantage
to the changeset approach when there is a large amount of patching
between branches, but that hasn't ever been the case in GnuCash.  The
GnuCash tree is very sparse, and most branches are terminal release
branches.  Even if the tree wasn't sparse, I don't foresee the need to
cross patch branches like there is in kernel development.

> before CVS came out?!  You've .. um... been around a while, eh?  :)

I've been around longer.  :-)  I did the RCS to CVS conversion for Cisco
Systems in 1990, and wrote the original set of multi-directory
commit/logging scripts that are now part of the CVS distribution.

While Subversion may not be perfect (is anything) or "the best", I
believe its adequate for our needs.  Yes it is centralized, but I have
no problem with that.  If you want distributed support it appears you
can get that by running svn+svk locally.  Assuming we choose subversion
I plan to try just that, but it appears that subversion has already been
tweaked so that my most common operation, diffing my changes against the
base code, already operates fully offline.  That eliminates the main
reason I would have for wanting a distributed system.

David


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Switching from CVS to Subversion: test svn repo available

Chris Shoemaker
In reply to this post by David Hampton-2
On Mon, Oct 24, 2005 at 03:20:15PM -0400, David Hampton wrote:
> On Mon, 2005-10-24 at 14:52 -0400, Chris Shoemaker wrote:
>
> > It kind of makes me want to respond like others have [1],
> > but I want to remain constructive.
>
> If you wanted to remain constructive you wouldn't have posted that URL.

:( You're right, David.  Thank you for pointing out my hypocrisy
without being mean.

Derek,

        I apologize for dredging up the past like that.  I said I
wanted to remain constructive, but my actions said otherwise.  I wish
I could take it back.  I /will/ try to exercise more self-control in
the future.  Please forgive me.

Regretfully,

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
1234