congif spec in GIT

congif spec in GIT

[Radu Manea]

Hi,

Thank you for the detailed presentation posted on git.or.cz site.

One question: is there any equivalent config spec file for GIT as is in 
ClearCase today?

Thanks,
Radu M.
+40 21 203 6611

Re: congif spec in GIT

[Neal Kreitzinger]

On 7/6/2012 6:46 AM, Radu Manea wrote:
>
> Thank you for the detailed presentation posted on git.or.cz site.
>
> One question: is there any equivalent config spec file for GIT as is in
> ClearCase today?
>
I don't know clearcase, but have you looked at git-config manpage?
http://git-htmldocs.googlecode.com/git/git-config.html

v/r,
neal

Re: congif spec in GIT

[Robin Rosenberg]

Radu Manea skrev 2012-07-06 13.46:
> Hi,
>
> Thank you for the detailed presentation posted on git.or.cz site.
>
> One question: is there any equivalent config spec file for GIT as is in ClearCase today?

Repo (http://source.android.com/source/version-control.html) is perhaps
the tool that is most similar in functionality to the config spec. It allows you
to perform operations over multiple repositories.

-- robin

Re: congif spec in GIT

[Torsten Bögershausen]

On 06.07.12 13:46, Radu Manea wrote:
> Hi,
>
> Thank you for the detailed presentation posted on git.or.cz site.
>
> One question: is there any equivalent config spec file for GIT as is in ClearCase today?

There are similarities, and differences between git and ClearCase,
I can only point out the very basic differences,
because the philosophy of these 2 tools is completely different.


CC has a "virtual file system", often mounted on /vobs on Unix,
and M:\ (or another drive name) on Windows.

CC simulates a file system, where files are seen according
to the config spec. Changing the config spec will change the
version of the files seen under /vobs immediately.

If you want a copy of all the files on your local disk,
you need to create a "snapshot view". After changing
the config spec, the snapshot view needs to be updated.

git always has a "working tree", similar to a "snapshot view"
(except for "bare repositories", they correspond to a CC server)


CC uses branches
git uses branches

CC uses labels
git uses commit ids, A tag may point to a commit id

CC defines for each file/directory which label is used
    When a file is checked out, a branch is created for that file element
   different directories may use different branches
- git uses the same branch for the whole repo

CC uses labels for each directory, whatever the config spec say for that 
very directory.
- git uses a commit id as a base for that branch.


So if try to transform "a branch in git" into a config spec,
we do:

$ git status
# On branch my_feature_branch
  (and that branch is defined on the whole working tree, similar to 
/vobs/projects/git/tb)

If I open the "engine bonnet" of git, to see what that means 
technically, I run on the command line:

$ cat .git/HEAD ref: refs/heads/my_feature_branch
(we are on branch my_feature_branch)

When I dig further:

$ cat .git/refs/heads/my_feature_branch
a5b0a8ff7f48cfd5ea19712680c64a029e99c2ba

We see that my branch is taking commit a5b08ff7 as a base line


So a "config spec" could include 3 lines, kind of
"all files are CHECKOUT/CHECKIN"
"All files are based on commit id a5b0a8ff7f48cfd5ea19712680c64a029e99c2ba"
"If you commit one or more files at once, they are recorded on branch 
"my_feature_branch"

HTH
/Torsten