Le 31 janv. 06 à 01:35, Andy Ruder a écrit :
On 1/30/06, Quentin Mathé <[EMAIL PROTECTED]> wrote:
[...] should probably be broken in several sections too. Feel free
to reuse
it if you want to add more documentation on GNUstep wiki.
Here is the link <http://www.dromasoftware.com/etoile/mediawiki/
index.php?title=Source_Repository>
Thanks I will take a look. I would especially like to look at setting
up some sort of guide
to using svk if you so choose. I've been using svk quite a bit lately
and have found
it very useful in many situations.
I agree. In fact, my intent with this page has been to write a guide
which provides instructions for both SVN and SVK.
Why not. But I'm not sure to understand, is it still possible to
checkout only 'core' (make, base, gui, back) in one pass ? With
devmodules/core right ?
Yes, if you look at /devmodules it basically has 5 empty directories
in it (core, dev-apps, dev-libs, usr-apps, tests). So what you can do
is set a property on these directories called "svn:externals" that
tells the svn client to checkout some other repository into a
subdirectory when it is checked out.
So, when you checkout this directory, it'll checkout the stuff in
core/ then it'll checkout
svn+ssh://svn.gna.org/svn/gnustep/libs/gui/trunk into core/gui and so
on. /devmodules
has what I figured would be the "standard" sets of libraries, apps,
etc,
ok, I understand better now, it works well in my test.
Well, except I have to type my ssh password for every external
references, that's a real pain when you checkout the whole
'devmodules' content. It's even worse because I have this issue when
I update my working copy too (five passwords to type when I update
'core').
Any solutions ?
And then, everytime I do a fresh checkout on that directory I just
created, I would have
an environment tailored to what I generally want svn of including
whichever branches, tags, etc. that I want to work from. Heck, I
could even add a file into my checkout/ directory
to do a full compile of everything (including gorm) tailored to my
system... things like this
make a /developer/<name> hierarchy advantageous (imo). Not to mention
the benefits derived from just having your own private sandbox to play
around in (testing branches and merging changes into them or what
not).
I'm all for this possibility.
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
