1. Questions about SVN check-in policies for binaries
As I start using my working copy of the svn repository for Euphoria, I am asking
myself a couple questions about what I'll check in soon. Perhaps these points
deserve to be written somewhere in the repository.
1/ Is any developer supposed to have access to all platforms and compilers
supported?
If the answer is "no", then there is some unpredictability about what will be
checked in in /bin. For instance, since I don't have lcc installed, I won't
generate the lcc libs, and as a result they won't be in sync with libs I may have
modified.
Likewise, if I build say exw.exe, I may not be able to build exu. As a result,
the contents of the checked /bn will reflect different states of the software
again.
2/ (related, yet distinct) Since there is only one exu, one exw.exe etc, but
since there is a plethora of compiler, compiler version and compile options under
which the checked in executables may have been built, this is another cause of
discrepancy and subtle bugs (because the executable was built with this compiler
by the last developer, and not that one). And I'm not even considering the case
where a zealed developer will have cross compiled all the executables, in case it
is possible.
3/ DOS/Windows developers will return source files with /r/n line endings, and
Linux/BSD developers will returns /n line endings. When Mac people chime in, they
may have /r line endings. How is this other source of discrepancies handles? Ok,
perhaps the answer here is: the subversion client takes care of this.
A simple way to avoid the confusion about binnaries could be not to check
binaries in at all. But I think there is a need for a clear statement about what
to do.
CChris
2. Re: Questions about SVN check-in policies for binaries
CChris wrote:
>
> A simple way to avoid the confusion about binnaries could be not to check
> binaries
> in at all. But I think there is a need for a clear statement about what to do.
>
I, personally do not check in binaries. Rob uses that for distribution
purposes. As far as I'm concerned, I'm only really interested in checking
in source (or documentation) changes, and I'll build whatever binary I
require.
Matt
3. Re: Questions about SVN check-in policies for binaries
- Posted by Robert Craig <rds at RapidEuphoria.com>
Jun 20, 2007
-
Last edited Jun 21, 2007
CChris wrote:
> As I start using my working copy of the svn repository for Euphoria, I am
> asking
> myself a couple questions about what I'll check in soon. Perhaps these points
> deserve to be written somewhere in the repository.
>
> 1/ Is any developer supposed to have access to all platforms and compilers
> supported?
No, but you should be able to build on at least one platform,
so you can test your changes at run-time to some extent
before checking them back in.
> If the answer is "no", then there is some unpredictability about what will be
> checked in in /bin. For instance, since I don't have lcc installed, I won't
> generate the lcc libs, and as a result they won't be in sync with libs I may
> have modified.
> Likewise, if I build say exw.exe, I may not be able to build exu. As a result,
> the contents of the checked /bn will reflect different states of the software
> again.
True.
> 2/ (related, yet distinct) Since there is only one exu, one exw.exe etc, but
> since there is a plethora of compiler, compiler version and compile options
> under which the checked in executables may have been built, this is another
> cause of discrepancy and subtle bugs (because the executable was built with
> this compiler by the last developer, and not that one). And I'm not even
> considering
> the case where a zealed developer will have cross compiled all the
> executables,
> in case it is possible.
>
> 3/ DOS/Windows developers will return source files with /r/n line endings, and
> Linux/BSD developers will returns /n line endings. When Mac people chime in,
> they may have /r line endings. How is this other source of discrepancies
> handles?
> Ok, perhaps the answer here is: the subversion client takes care of this.
It's possible that the subversion client handles this.
I haven't seen any problems like this.
> A simple way to avoid the confusion about binnaries could be not to check
> binaries
> in at all. But I think there is a need for a clear statement about what to do.
I would say, don't bother to check in your binaries
(executables, libraries, etc), just your source (and documentation).
Currently, I am the one who makes the official releases,
so I figure there is some value in my checking in
executables periodically, so others can test them if they want,
before I do a release.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Questions about SVN check-in policies for binaries
Robert Craig wrote:
>
> CChris wrote:
> > As I start using my working copy of the svn repository for Euphoria, I am
> > asking
> > myself a couple questions about what I'll check in soon. Perhaps these
> > points
> > deserve to be written somewhere in the repository.
> >
> > 1/ Is any developer supposed to have access to all platforms and compilers
> > supported?
>
> No, but you should be able to build on at least one platform,
> so you can test your changes at run-time to some extent
> before checking them back in.
>
looks like a decent minimum to ask.
> > If the answer is "no", then there is some unpredictability about what will
> > be
> > checked in in /bin. For instance, since I don't have lcc installed, I won't
> > generate the lcc libs, and as a result they won't be in sync with libs I may
> > have modified.
> > Likewise, if I build say exw.exe, I may not be able to build exu. As a
> > result,
> > the contents of the checked /bn will reflect different states of the
> > software
> > again.
>
> True.
>
> > 2/ (related, yet distinct) Since there is only one exu, one exw.exe etc, but
> > since there is a plethora of compiler, compiler version and compile options
> > under which the checked in executables may have been built, this is another
> > cause of discrepancy and subtle bugs (because the executable was built with
> > this compiler by the last developer, and not that one). And I'm not even
> > considering
> > the case where a zealed developer will have cross compiled all the
> > executables,
> > in case it is possible.
> >
> > 3/ DOS/Windows developers will return source files with /r/n line endings,
> > and
> > Linux/BSD developers will returns /n line endings. When Mac people chime in,
> > they may have /r line endings. How is this other source of discrepancies
> > handles?
> > Ok, perhaps the answer here is: the subversion client takes care of this.
>
> It's possible that the subversion client handles this.
> I haven't seen any problems like this.
>
> > A simple way to avoid the confusion about binnaries could be not to check
> > binaries
> > in at all. But I think there is a need for a clear statement about what to
> > do.
>
> I would say, don't bother to check in your binaries
> (executables, libraries, etc), just your source (and documentation).
>
> Currently, I am the one who makes the official releases,
> so I figure there is some value in my checking in
> executables periodically, so others can test them if they want,
> before I do a release.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
It looks like we mostly agree on this. Perhaps writing it down in the source
overview.doc isn't a bad idea?
CChris
5. Re: Questions about SVN check-in policies for binaries
CChris wrote:
> It looks like we mostly agree on this. Perhaps writing it down in the source
> overview.doc isn't a bad idea?
Yes, I need to write down somewhere the guidelines for
working on the official SVN source code. It's still
early days though, so I don't want to be too rigid or detailed.
I'm sure new ideas will arise as we work together on this.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
