> Seriously, how hard
> is it to make a build environment with a script that modifies what should be
> modified on checkout? I don't see the extreme problems here with "fossil
> update" followed by "bin/convert" where the latter is a script specific to
> your project that converts only the files that need to be converted for the
> target platform.
>
This could be a solution for checking out and creating a release in the target
platform but this is not a solution useful to develop in both, unix and windows.
It is not enough to convert after checkout or update. What about commit, what
about diff? It just does not work.
The only alternative that I understand as possible with current fossil is:
1) Remember to manually covert any new file to unix line endings before
first commit (if you develop on Windows)
2) As some developer, for sure, will forget to do it on Windows, be prepared
to modify the file in the future and commit again. In this case, diff with
older versions will be seriously damaged
3) When you incorporate a new developer in the team, he will, for sure,
try that new-super-mega editor that will save the file with windows
line endings. Problems again
4) When you are creating a installer or distribution on Windows, create
a tool to convert to windows line endings all the ascii files that will be
included in the distribution as-is (README, License, examples, etc.)
5) Be prepared for strange things that are going to happen in the future
that I cannot even imagine now
A solution to alleviate this problem could be something similar to a foreign
key constraint, where it was possible to avoid, in some way, that people
commited files inside fossil with windows line endings
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
