Re: Recommend we don't support users running built dojo on a git/hg/svn branch

On 01/08/16 13:55, Chris Travers wrote:

On Mon, Aug 1, 2016 at 5:15 AM, David G <..hidden..> wrote:

On 30/07/16 23:45, Chris Travers wrote:
> On Sat, Jul 30, 2016 at 2:20 PM, David G <..hidden..> wrote:
>> Hi Chris,
>>
>> In the past I would have to have agreed with you, however, in the last few
>> days, ylavoie (irc/matrix) has implemented a git based technique to handle
>> correct rebuilding of dojo only when needed for the travis tests.
>>
>> I believe the "exact" same technique can be used to resolve the issue on
>> production installations as well.
>> However in a production environment, rather than "automatically" rebuilding,
>> we can simply block login at the login page with a message that dojo modules
>> need to be rebuilt.
> Also aside from the fact that our build process should not be based on
> whatever version control software someone happens to be using, would
> it not make a lot more sense to just note in the log that dojo might
> need to be rebuilt and that performance will suffer and fail back to
> using non-built?
I agree that we probably need to allow for people that want to use
NON-GIT VCS, can you send me a patch off list for your current changes
to Makefile and I'll see about catering for git and hg OOTB

All I did was remove the git checkout for the README. On submodules, note that the concept is not that well defined and so vcs's handle this differently (and iirc there are even plugins to change how git handles them).

Ok, so that's an easy enough item to cater for.

Unfortunately simply falling back to src isn't necessarily the best option.
As we now have dojo as a submodule it's quite possible that the
submodule (and therefore dojo src) may be out of date as well.

This would still work solidly on Mercurial btw since subrepos are pulled on every pull. But that it would not work reliably on git is a good reason not to do it.

The only robust solution I can conceive is to
* compare available built version against expected version, and use
the built version if there is a match
* else compare available src version against expected version, and
use the src version if there is a match
In this case we also should notify on the login page that we are
using dojo src (can be unobtrusive but should be easy to point people at)
* else Block Login with a sane error message stating that installed
dojo modules are out of date and need to be updated/rebuilt

Mercurial is actually pretty solid when it comes to submodule support. Subrepos, as they are called, are transparently included, pulled on every pull command, and updated when you do an hg update. So for HG users, you can assume that the submodule is always up to date.

To be honest the submodule issue is one reason I would recommend Mercurial as a production repo for 1.5 -- people complain about git submodules causing problems, but with Mercurial, they just work as if they are a part of the parent repository. No intervention needed.

Git has better handling of whitespace on merging and better handling of merging moved files. But Mercurial solved the integration issue for subrepos flawlessly. So for mercurial, you can ignore the submodule problem.hg clone, pull, and up take care of those through normal operations.

So, since the concerns are different, my recommendation would be to skip the question of submodule updates if the person is using Mercurial (i.e. if .hg/hgrc exists).

Ok, thanks for the nice easy test to make the Makefile handle hg easily ( I've not used hg myself so was going to ask when I implemented it)
I actually have a rework of the makefile sitting in the wings, it breaks it up into logical chunks that get included depending on distro etc.
I'll add variations for different VCS as well.

>> This actually fits in with some other changes I have planned for the login
>> screen over the next 7 days, so I'll take ownership and prepare a PR that
>> covers this as well.
>>
>> Regards
>> David G
>>
>>
>>
>> On 29/07/16 00:16, Chris Travers wrote:
>>
>> Hi;
>>
>> I spent a fair bit of time troubleshooting a bug that turned out to be a
>> missing make dojo step. I know the user who reported it had trouble with
>> the make dojo step and it didn't seem like a widget bug to me until I got
>> fairly deep into it.
>>
>> In the past we have supported people running LedgerSMB directly out of code
>> repos or checkouts. I think we should continue to do that, but we really
>> cannot guarantee that dojo gets rebuilt every time it should in these cases,
>> so I think we should explicitly say that running with built dojo on a branch
>> (stable or not) is not supported.
>>
>> The built dojo strikes me as mostly useful when people are installing from
>> packages and so we are providing the built libraries. But if we aren't
>> providing the built libraries, then we can't be sure which versions they are
>> using.
>>
>> As a side note, i think we also need to really carefully think about how we
>> can properly handle cache invalidation in our current approach.
>>
>> Unless there are any objections, I will put a note saying that running with
>> dojo_built=1 from git, hg, svn, etc is unsupported. I think that will avoid
>> a lot of effort on our part and a lot of headache for would-be users.
>>
>> --
>> Best Wishes,
>> Chris Travers
>>
>> Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
>> lock-in.
>> http://www.efficito.com/learn_more
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Ledger-smb-devel mailing list
>> ..hidden..
>> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Ledger-smb-devel mailing list
>> ..hidden..
>> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>>
> ------------------------------------------------------------------------------
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>

------------------------------------------------------------------------------
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

--

Best Wishes,
Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.

http://www.efficito.com/learn_more
------------------------------------------------------------------------------
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel