[fpc-devel] SVN error with macosall.pas

[Graeme Geldenhuys]

2009/7/11 Jesus Reyes <jesusrmx at yahoo.com.mx>:
>
> I think this is a feature and not a bug,

Yes, it is how SVN works to show you the original file, but it waists
a lot of space (double everything) and it pollutes the directories, so
you can't quickly archive the "checked out" directories without
pulling in all the .svn one. Alternative is to first export to another
location and then archive that. Git you don't have to worry about
that, plus Git has the 'git archive' command which does exactly want I
intended in the first place - very nice for creating releases.

> It would be nice if the same thing could be made with git,

There are many ways to get hold of the original file in the
repository. 'git cat' is just one of them, 'git show' is another. But
'git diff' does an excellent job by itself. It has built in pager
support, so you can scroll up and down through the diff output, git
does color highlighting for your, git also has a pascal language diff
improvemnt, so the hunks in the pach (text starting with @@) contains
the class name, method name etc.. to which the hunk relates - I find
the latter *very* handy.

Then you can also tell git against what you want the diff. If you made
many local commits you can compare against them, or if you want to
compare against the original version still in "upstream" or "master".
You can obviously also do diffs against any revision back in time by
specifing the revision, x days ago, etc...

> and even as git can hold whole history, it would be interesting to choose any
> specific revision to do the diff, how?

Git does not use incremental revision numbers because it is a
distributed SCM, so which revision number will be the true revision
number? That is why git instead uses a SHA1 which was generated from
each commit. This has many advantages. If you want to know if you have
the same version as somebody else, you only need to look at the SHA1
instead of the commit details - this is obviously very fast. This also
helps merges, etc... so git can easily detect if a local commit which
was submitted as a patch and then came back through "master" or
"upstream" (patch was accepted at applied), git can savely remove the
local commit and apply the new one instead.

If to different repositories had different development paths, but a
specific commit ended up havening the same SHA1, it means they file is
now exactly the same, no matter the history it took to get there.

In Git you don't have to specify the whole 40 character SHA1, normally
the first 7 characters is enough to uniquely identify a SHA1. I must
admit, SHA1's were something to get used to, because all previous SCM
systems I used, had incremental revision numbers. But SHA1 is more
than just a "number" in Git, it tells you that it is cryptographically
correct, and contains the history (including moved files, renamed
files, directory tree etc) of how you got to that file.

Now if you cloned a SubVersion repository and keep the Git repository
as a mirror (like I am doing with FPC and Lazarus), you mights still
want to reference the SubVersion revision number. Well, git has
support for that. First off, when git cloned the SubVersion repository
it added some meta data by default into the commit message (and a few
other places) telling you the repository and revision number it came
from. To reference a specific revision number like SVN does you can do
something like this:
   git log -r1354
   git log -r2000:2050 -v
   etc..


> btw how do git deals with revisions? with svn having a short number
> tagging a revision is handy even when it could make you crazy like

Well I think I explained that above. You can use any abbreviated
version of a full SHA1, though the first 6-8 characters are probably a
recommended minimum. Many git commands can be told to only show an
abbreviated SHA1 as well. Git also has some other formats you can use
which don't require a SHA1 value. HEAD for example points to the last
commit in a branch. ORIG_HEAD is the HEAD before you did some big
command like 'git fetch' (something like svn checkout). So if you made
a mistake, you can even undo the 'git fetch' command. You can also do
things like HEAD~4 which means 4 commits before HEAD. The number can
be as high or low as you want. You can use tags as well... v1.6~20
meaning 20 commits before the v1.6 tag etc...

It's hardly possible to loose something in git as well. You might have
deleted commits from history or undone your last days work etc...
Those commits might not appear in any branch or log anymore, but as
long as you did not run 'git plune', they are still available as
"dangling commits". You can obviously ask git to show you all dangling
commits, you can then use 'git show <sha1>' to view those and retrieve
them. It is recommended to create a sandbox repository and play around
with such commands to get used to the idea that things don't just get
lost. This allows you to experiment with more commands a lot quicker.

The git mailing list is also a very friendly environment and they do
not mind answering questions from any experience level.

Regards,
  - Graeme -


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