My main concern is what happens when people contribute changes to sources in
public Csound5 CVS.

Will John Fitch update his private sources with others' changes so that when
he commits his own changes to CVS, the changes will be merged, or will
John's changes simply overwrite other contributions? This has happened with
my changes several times now.

I don't think John intends this, but obviously it causes a real problem, so
much so that I've stopped contributing to Csound5 until we can resolve this.

============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
CsoundVST, an extended version of Csound for programming music and sound
Available at http://sourceforge.net/projects/csound/
============================================


----- Original Message ----- 
From: "stevenyi" 
To: "Csound Developers Discussion List" 
Sent: Wednesday, March 17, 2004 4:19 AM
Subject: [CSOUND-DEV:4355] Re: Getting in step


> >                                                                 If a
good number of
> >  stevenyi> us here are looking at auto-configuring build systems, don't
you think
> >  stevenyi> maybe there's a real issue at hand and denying that a problem
exists
> >  stevenyi> really won't help get Csound to build on everyone else's
computer?
> >
> > That is correct; I do not think there is a problem.
> >
> >  stevenyi> I have never had Csound build out-of-the-box except in the
cases of the
> >  stevenyi> Autotools build for Csound4 and now the SCons system in
Csound5.
> >
> > I built csound4 on six different platforms without confusions of
autotools
>
>
> You have your experience and I have mine (Redhat 9, Fedora Core 1,
> Win98, Win2k, WinXP, and MacOSX 10.1 and 10.2, all from the past
> month).  Granted, two of these OS's I tested on are on virtual machines
> using VMWare, and one system is SourceForge's compile farm.  I'm really
> not making any of this up for the sake of arguing; I really just want to
> find the solution that will work out for you and everyone else here and
> all I can offer is what I've come across.
>
> >  stevenyi> Autoconf and SConstruct both address the same issues of
analyzing the
> >  stevenyi> system being built on and building the sources depending on
what's
> >  stevenyi> available.  By automating this, builds becomes easier to do
as the
> >  stevenyi> person building doesn't have to spend time tracking what they
have and
> >  stevenyi> configuring the Makefile as it configures itself.
> >
> > Disagree.  My experience is that it means that no time is spent on the
> > code and all available time is spent attempting to get the autoconf
> > to run.
>
> Well, I would say I agree and disagree then.  Autoconf I liked as it was
> working for me on different platforms but I found it difficult to make
> my way through the file so it was hard to make changes.  SCons I found
> to be really nice for me as it so far has worked out for myself and it
> is easy for me to edit and builds seem to run faster. I find changes to
> the build system easier to manage with an SCons file than a Makefile.
>
>
> >  stevenyi> Regardless, the build system issue is a moot point now.  You
have your
> >  stevenyi> Makefile's in the CVS.  The SConstruct file does not generate
any files
> >  stevenyi> that can possibly overwrite your Makefile's (as was the case
with the
> >  stevenyi> Autotools).  The two systems can coexist without problems so
hopefully
> >  stevenyi> we can all have access to build systems that will work for
each of us.
> >
> > The trouble is that structures are being changed and I do not know.
> > Look, the CVS system was not even updating all my files, if I did a
> > complete new d/load I was presented with a system that did not compile.
>
> For structural issues, perhaps we should all get in the practice of
> using some kind of header in the subject line of our email, something
> like:
>
> [BUILD CHANGE] - File moved from here to there, etc.
>
> I'm sure you, like myself and others here, get *way* too much email in a
> day.  Perhaps this would be the best way for any of us to extend the
> courtesy of letting others know what changes are in concrete terms.
> Alternatively, we could add such messages to the ChangeLog so as not to
> flood this list.
>
> As for CVS, I have no idea.  I have never had issues with CVS on csound
> or blue in terms of updating files with the exception of when
> SourceForge was doing maintenance and the CVS was not accessible.  I
> also regularly do complete fresh checkouts to test compiles.
>
>
> >  stevenyi> The only thing now is to keep them in sync, so if files are
reorganized
> >  stevenyi> in one build system that they are updated in the other build
system.
> >
> > That is precisely what I have been attempting to do.  From where I sit
> > others were arranging that I was not in sync
>
> Well, I think everyone is a little out of sync at the moment, as there
> are files in the CVS that seem to be relevant to the SConstruct build
> and not yours, and vice versa.  The CVS also needs tidying in general as
> there are file in there that don't need to be (generated files from
> builds, i.e. .xmg files; duplicate ugens6, 7, and 9 in Opcodes and OOps;
> etc.).
>
>
> >  stevenyi> As for ustub, please see:
> >
> >  stevenyi>
http://eartha.mills.edu:8000/guest/archives/CSOUND-DEV/log0402/msg00005.html
> > says that something is going to happen
> >  stevenyi>
http://eartha.mills.edu:8000/guest/archives/CSOUND-DEV/log0402/msg00007.html
> > was while I was explaining thatI could not even get a system that
> > compiled.  Neither of these explain what had changed.
>
> >From Michael's message in the second link above:
>
> Summary of changes:
>
> I introduced one Makefile.am to build all targets.
>
> I renamed some files in the anal and util directories to avoid duplicate
> filenames.
>
> Most opcodes are now working plugins.
>
> I moved a few opcodes from Opcodes back to OOps due to complex
> interdependencies.
>
> The Csound console executable links with the Csound API.
>
> I added code to csoundLoadExternals to automatically load all plugin
opcodes
> in $OPCODEDIR (on systems with dirent.h).
>
> I added a Top/ustub.c file to work with ustub.h and to replace duplicate
> code collected from utility sources.
>
> I added a libustub.a library containing ustub.c and a good chunk of csound
> to link all utilities.
>
>
> >  stevenyi> I guess I was aware of it from the autoconf builds as well as
from
> >  stevenyi> reading the CVS annotations when doing updates; I can see how
it may
> >  stevenyi> have gotten missed though.
> >
> > OK for you, but the autoconf never never ever built for me.  As I do
> > not know the language with is used for autoconf it never occurred to me
> > to read it.  Actually I wanted to get the sound library fixed.
>
> Yes, like I said, I can understand how this got missed.  I'd like to
> move past all of this as well and get to rebuilding some opcode plugins
> I have here for csound5 and testing out the API with Java amongst other
> things.  Since I do understand the SCons file and the Makefiles, I'll
> try to spend some time figuring out what are the differences.  Hopefully
> we can all get back in sync soon and move on to other things.
>
> Thanks,
> steven
>

>>>>> "Michael" == Michael Gogins  writes:

 Michael> My main concern is what happens when people contribute changes to sources in
 Michael> public Csound5 CVS.

 Michael> Will John Fitch update his private sources with others' changes so that when
 Michael> he commits his own changes to CVS, the changes will be merged, or will
 Michael> John's changes simply overwrite other contributions? This has happened with
 Michael> my changes several times now.

 Michael> I don't think John intends this, but obviously it causes a real problem, so
 Michael> much so that I've stopped contributing to Csound5 until we can resolve this.

I have spent 3 days merging files, while attempting to keep a
buildable system.  As far as i can tell csound itself builds but the
anal/util trees are in various states of disrepair.  I updated a bunch
this morning but did not commit

On the other hand, from my point of view you have been committing
files which overwrite my changes.

==John ffitch

So, the question here, I believe, is "what is the correct way for everyone
to use CVS?"  I haven't used CVS except to anonymously check out sources, so
I am a little bit confused.

Isn't CVS supposed to manage merging changes?  Shouldn't CVS merge changes
from a commit and not wholesale replace the files?

How does CVS handle the situation where I do a fresh check out, modify some
files, but before I can submit my changes, someone else has already commited
other changes to the same files?  If CVS won't properly merge the changes,
and rechecking out the files will overwrite my changes on my local machine,
then how is anyone supposed to resolve this situation?

Anthony Kozar
anthony.kozar@utoledo.edu


On 3/17/04 9:38 AM, jpff@cs.bath.ac.uk etched in stone:

> "Michael" == Michael Gogins  writes:

>> that when he commits his own changes to CVS, the changes will be merged, or
>> will John's changes simply overwrite other contributions? This has happened
>> with my changes several times now.

> On the other hand, from my point of view you have been committing
> files which overwrite my changes.

Due to a recent snow boarding accident, I must greatly restrict the
amount of time I spend using a keyboard.  As a result, I will not be
trying out SCons for the csound4 module anytime soon.  If this is
deemed to be an important task, someone else must take it on.

John