r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 Source Control] How to manage build process

Pekr
29-Oct-2010
[146]
... but you would not have to constantly announce it - it could save 
you a bit of work, no?
Henrik
29-Oct-2010
[147x2]
Pekr, that's simply a snapshot, which takes a minute to do, thanks 
to our build system.
GrahamC, RM Asset uses SVN.
GrahamC
29-Oct-2010
[149]
there's likely an automatic tool to export from SVN to git
Maxim
29-Oct-2010
[150x3]
distributed source controls are much more flexible and easy to use 
than centralized ones like svn.
there is no concept I have to put it *the* repository.
its easier to do a grid of different setups. not just a linear sequence 
of versions.
Gabriele
29-Oct-2010
[153]
I haven't yet seen a good argument that Git is better (than Hg, at 
least)

 - Brian... so... people who have used both for years can be just 
 ignored I guess.


Just read how they work, if it's not obvious why GIT is better, then 
I don't know what to say.
Cyphre
29-Oct-2010
[154]
I don't have experience with Git(only used Hg) and I have nothing 
against learning and using it. The only thing I hate about it so 
far is the lost 1GB!! of diskspace after installing TortoiseGit for 
Windows :)
Maxim
29-Oct-2010
[155x2]
holy cow ... 1GB !
I mean... didn't I use an OS that fit on a 512kb rom just 10 years 
ago... seems like a lifetime ago.
Cyphre
29-Oct-2010
[157x2]
well, that's all the msys stuff that is needed to run the git, unfortunately
this aproach is like 'hey, you need the whole OS for my app, I don't 
care what you are using"
Henrik
29-Oct-2010
[159]
The idea of GIT might be good, but where do we end up, if we suddenly 
rely on 3-5 different systems that require a 10GB installation of 
all sorts of unmanagable components?
Maxim
29-Oct-2010
[160x2]
once we have ssh on r3 (in whatever form) I think we should be able 
to build the entire git toolset with REBOL at a fraction of msys 
stuff.  I already did a complete source control system (though with 
a completely different model) called distro-bot and its hardly 1GB!
rebol in and of itself already does most of the low-level OS stuff... 
just two days ago... I used R2 as a delete function in order to polish 
a windows GCC script.  this strikes me as a similar situation where 
rebol could be used to probably replace a sizeable portion of the 
msys stuff... though it might not be as fast and optimised... that 
I do concede.
Oldes
29-Oct-2010
[162]
Why you would need 1GB for TortoiseGit? I installed this:

http://code.google.com/p/msysgit/downloads/detail?name=Git-1.7.3.1-preview20101002.exe&can=3&q=
and it seems to be enough.
Cyphre
29-Oct-2010
[163]
I don't know why it was so big..I installed it half year ago, maye 
they fixed that. I guess your link is just some cli version? I want 
gui version.
Ladislav
29-Oct-2010
[164]
Yes, msysgit is just a CLI
Cyphre
29-Oct-2010
[165]
When looking at my pc I installed this in these days: msysGit-fullinstall-1.7.0.2-preview20100309.exe 
then installed Tortoise over it.

Then when I check size of c:\msysgit\ dir I got 1 307 758 191 bytes


I'll try to uninstall and use the latest version to see if it is 
better.
Oldes
29-Oct-2010
[166]
No, it has gui as well.
Andreas
29-Oct-2010
[167x4]
gitk and git-gui, yes.
tortoisegit just adds a kind of explore integration that many are 
already familiar with.
Another option for explorer integration would be Git Extensions:
http://code.google.com/p/gitextensions/
(And yes, even plain msysgit comes with minimal, optional explorer 
integration in the form of "launch a git shell here" and "launch 
git gui here", if I remember correctly.)
Oldes
29-Oct-2010
[171]
The installer from my link above adds the explorer extension as well.
Cyphre
29-Oct-2010
[172]
Oldes, thanks for the link to the latest version. This seems to be 
better..'only' 180MB :-)
Carl
29-Oct-2010
[173x2]
Quick notes:


I downloaded via the Git link that Oldes posted above. It's ~12MB 
(reasonable.)


Installed fine on XP.  Yes, this is a shell version, which is fine 
with me since I like to use scripts anyway for merges, builds, and 
releases.


I have yet to try git with github. It would be great if someone could 
post the magic command line to checkout  the existing repository 
(anonymous currently),


Regarding GUI version: it would not be difficult for someone to wrap 
a few REBOL calls it to give you a bit more GUI feel. Not perfect 
of course, but something clickable.
So, next steps for A110 in git are:


1. Obtain a user account on github. (with the permissions I need 
from Andreas.)


2. Commit new A110 sources to github. (probably an overwrite, not 
a merge)


3. Commit A110 libs to github. Binary, compressed, and version/platform-dependent.

4. Tag it all as A110 (however that's done in git).


Does this sound about right with you git gurus?  Let me know of any 
special steps, proceedures, so this can happen today.
Oldes
29-Oct-2010
[175]
I'm using Git second day, so I'm far to be called git guru, but I 
think that you could just obtain account without Andreas' permissions 
and commit the sources under your name.
Carl
29-Oct-2010
[176x3]
Checklist created: Git Move -- steps for A110 git-based release
Andreas, feel free to update checklist with any additional things 
that you want to add.
Oldes, mostly. There was something he mentioned to me earlier.
Andreas
29-Oct-2010
[179]
To clone the current repository:
$ git clone git://github.com/rebolsource/r3-hostkit.git
Carl
29-Oct-2010
[180]
Ok, so that's like a checkout?
Fork
29-Oct-2010
[181]
http://eagain.net/articles/git-for-computer-scientists/
Andreas
29-Oct-2010
[182]
Yes, that's somewhat like a checkout.
Carl
29-Oct-2010
[183x2]
Worked. Got it. Nice.
git move checklist updated
Fork
29-Oct-2010
[185]
The general model is that if you plan on making changes to the codebase, 
you usually would "fork" (lowercase) the project on the GitHub site. 
 It is not typical for people to give write access to others on their 
repository.  So that URL ( git://github.com/rebolsource/r3-hostkit.git 
) is read-only.
Andreas
29-Oct-2010
[186x5]
Carl was referring to something else, I reserved the "rebol" username 
yesterday.
Carl, to "overwrite" your local stuff with the new sources, just 
remove everything but the .git/ directory.
Then copy over your changed sources and do a "git add -u .".
A "git diff --cache" will then show you the changes compared to the 
last commit.
Use "git commit" to commit those changes.
Fork
29-Oct-2010
[191]
When there are various tracks of development on forked repositories 
at GitHub, you can see the state of their convergence (or divergence) 
with the network graph visualizer: http://github.com/blog/39-say-hello-to-the-network-graph-visualizer
Andreas
29-Oct-2010
[192]
Gotta run now, will be back in 30 minutes.
Fork
29-Oct-2010
[193x2]
But you do not get that if you just clone someone else's repository 
in a read-only fashion... i.e. with the clone command " git clone 
git://github.com/rebolsource/r3-hostkit.git ".  It's easy enough 
to fix later, but you can do it up front by starting with a fork 
if you know you are planning on making changes and sending them back 
to the project.
A nice feature worth noting is that GitHub automatically makes .ZIP/.tar 
for you (note the downloads button).  Available at links like http://github.com/rebolsource/r3-hostkit/zipball/master
BrianH
29-Oct-2010
[195]
Gabriele, it is obvious that both Git and Hg have their strengths 
and weaknesses related to each other, and the question is whether 
the tool plays to the strengths you need. One of Git's strengths 
is popularity, which has had a side effect of prompting the third-party 
development of addon tools that in many cases make up for its (not 
insignificant) weaknesses. I was not dissing Git when I said that 
its advantages was popularity - that is a considerable strength, 
not to be ignored. Things become popular for occasionally on-topic 
reasons, and it has real benefits no matter what the reason. Fortunately 
we have a good tool (REBOL) that we can use to work around Git's 
weaknesses.