[Lazarus] EXIF - como ler (how to read)?

[Guionardo Furlan]

As per Paul's request I started a new message thread...

[sorry Paul for all the previous OT messages]


Florian Klaempfl wrote:
>
> That's exactly my point: if somebody forgets it, things are screwed up
> and with every clone you've to play this game again.

Not really. core.autocrlf is automatically set to true for Windows versions
of Git (msysGit I know is) - the msysGit installation actually gives you a
choice, but the default is autocrlf = true under Windows.

Also, another simple way to prevent this whole EOL style issue, is to
actually clone the repository from the flashdrive drive, instead of using
it directly. Consider the repository on the flash drive as the "master"
repository. Clone it to your Windows partition using Windows version of Git
 and do the same for Linux. By default each cloned repository on each
platform will have the platforms native EOL style. Then pull/pull to that
"master" repository on the flashdrive from both Linux and Windows. Then you
don't have to ever worry about conflicting EOL styles. The repository on
the flash drive can even (preferred) be a "bare" repository, meaning it
only contains the git repository information (no branches are ever checked
out on the flashdrive).

Now lets continue using the above example and say that the Windows platform
is at home and the Linux platform is at work. And your flash drive contains
the "bare" master repository if you want to take work home. At work you can
add a second upstream repository which is the company server. So while at
work on your Linux system, you pull the changes from the flashdrive
repository (things you worked on last night at home), and then push those
changes back onto the company server repository.

Like I said, Git is a DSCM, so you need a slightly different thinking
compared to a client/server SCM like SubVersion. Hence the reason I would
suggest one re-evaluate ones workflow after adopting a DSCM, to make sure
it is still the most optimized workflow for your toolchain.


> You realize that fixes is not a feature branch but cherry picking? So
> what are the means to prevent that people look again and again to merge
> a certain changeset

Again a good reason to re-evaluate the workflow. I don't know how the Linux
Kernel project works, but the git.git project has a very nice workflow. At
fist it sounds confusing because it's quite different to how things are
normally done in say a SubVersion repository, but after reading there
workflow documentation once or twice you might notice how clever there
workflow is and how well it works.

For documentation on how the git.git project workflow works and what the
various "official" branches mean, see the following URL.

  http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html


git.git repository allows features to "graduate" from experimental to
release. All the while using feature branches which allows your to easily
thow-away that features or let it graduate upwards to a more stable or
release or maint branch.

Coming back to me "cherry-picking" for the fixes branches in Lazarus and
SVN Git mirror repositories. I use cherry-picking simply because both
Lazarus and SVN have linear development models which prevents me from using
many smaller "feature" branches and thus "merging". My only remaining
option was to use "cherry-picking" for FPC and Lazarus repositories.

At our office we have adopted a similar strategy to the git.git repository.
This allows us to much easier keep track of "maintenance" and new
experimental feature branches. And we have a MUCH smaller development team
and repository that Git itself - yet the workflow still applies well.


> How does this decrease the runtime of 5-30min (depending of the
> platform) of the regression test suite?

Not with the running time of the regression test suite, but in finding
regression bugs. With 'git bisect' you save a huge amount of time! I have
tried this on various regression bugs in Lazarus too, and it works very
well. In most cases I can create a small self-test application and
completely automate the finding of a regression bug.


Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/