[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: newbie: confused abt merging checkouts w/ co, up, sw ...

From: OpenMacNews <users-subversion.20.openmacnews_at_spamgourmet.com>
Date: 2004-01-11 23:42:30 CET

-- On Sunday, January 11, 2004 4:25 PM -0600 Ben Collins-Sussman <sussman@collab.net> wrote:

> On Sun, 2004-01-11 at 15:53, OpenMacNews wrote:
>> |
>> | -----dev_modules
>> | |
>> | | -- dev_module_1
>> | | | -- {dev_module_1_files}
>> | |
>> | | -- dev_module_2
>> | | | -- {dev_module_1_files}
>> |
>> | -----dev_themes
>
> Okay, so my first question: it seems like you've laid out the
> repository this way because you imagine three separate "projects": one
> project is named 'stable', one is named 'dev_modules', and one is named
> 'dev_themes'.

i'm not that clever! i laid out the repository this way cuz that's the way the Xaraya sources are arranged, in
seemingly three 'projects': stable, modules & themes

> But is 'dev_modules' really a project? Or is it just a directory
> holding a bunch of separate projects?

yes, it's a 'holding tank' for separately contributed/managed projects

> I mean, might it not be easier to think of 'dev_module_1' as a project?

easier? clearer? dunno ... to my way of thinking it depends on who's whiew you take. that of the individual
(dev_modules_N) 'projects', or of the Xaraya team's management-of-all-projects-as-a-project view ....

> I'll explain why I'm thinking this way further down.

< ... reading further ... >

>> doc_root
>> |
>> | -- {doc_root_files}
>> |
>> | -- themes/
>> | |
>> | | -- theme_1
>> | | | -- {theme_1_files}
>> | |
>> | | -- theme_2
>> | | | -- {theme_2_files}
>> | |
>> | | -- dev_theme_1
>> | | | -- {dev_theme_1_files}
>> | |
>> | | -- dev_theme_2
>> | | -- {dev_theme_2_files}
>> |
>> | -- modules/
>> |
>> | -- module_1
>> | | -- {module_1_files}
>> |
>> | -- module_2
>> | | -- {module_2_files}
>> |
>> | -- dev_module_1
>> | | -- {dev_module_1_files}
>> |
>> | -- dev_module_2
>> | -- {dev_module_2_files}
>>
>
> Okay, so you want to run 'svn checkout', and get a working copy
> structured like the above.

yup

> The good news is, you can certainly do that, using the 'svn:externals'
> directory property. It's similar to building a module in CVS. You
> would basically set this property on the repository's /stable directory
> to something like this:

'svn:externals'? ok, so i'm RTFM'ing ... (i clearly missed the 'shallow end of the pool' !)

> themes/dev_theme_1 http://host/repos/dev_themes/dev_theme_1
> themes/dev_theme_2 http://host/repos/dev_themes/dev_theme_2
> modules/dev_module_1 http://host/repos/dev_modules/dev_module_1
> modules/dev_module_2 http://host/repos/dev_modules/dev_module_2
>
> Now, when you run 'svn checkout http://host/repos/stable', you'll first
> get a complete copy of the 'stable' directory, and then you'll get 4
> "extra" checkouts happening within your working copy's themes/ and
> modules/ areas.

aha! cool! if i understand correctly, this'll do the trick ...

> The bad news is, if you add a new module or theme to the dev areas,
> you'll need to also add it to the svn:externals definition. There's no
> automated correpsondence.
>
>> (a) automate the 'bk get' of latest Xaraya dev files in the hierarchy they're maintained/presented
>> (b) integrate the Xaraya files into a svn-owned vms tree
>> (c) pull from svn into the working hierarchy that i need

fair enuf. can't have everything, i suppose ....

QUESTION:

i presume that when i *do* find a new Xaraya module in a bk checkout, i can simply add it to the svn hierarchy i've
created, and, likewise, then ADD to the svn:externals property, true?

do i then need to reinit/restart the svnserve daemon? or are property updates/changes dynamic?

> Replicating from bitkeeper to svn isn't a trivial thing... you might
> want to ask Ben Collins about his mirroring system. Hm.

"Hey Ben!" I'd like to ask about your mirroring system ...

thanks!

richard

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jan 11 23:43:13 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.