Sebastian Paul wrote:
> framework. This are includes, which reside in each project and so in many
> repositories. Now I tried to build a repository for this framework where
> these includes are kept together.
> The problem begins when checking out and referencing these includes.
> Where should the local working copy be stored?
1.
You could use svn:externals in the repository to reference the
framework repository.
Then you would store a working copy of the includes nested under each
project folder (automatically checked out by TSVN because of the
svn:externals).
Pros:
- If someone modifies a file in the framework, it will (hopefully) be
committed along with the change in the relevant project. Which gives
you knowledge of why it was done when you need to revert it ;-).
Cons:
- You'll have a bunch of local copys of the include directories
(space / TSVN speed)...
2.
You could store the include working copy in a known place in the filesystem.
That's what we do, and it's working perfect.
Every developer can check out the include directory wherever (s)he
wants, they just have to remember to do a:
SUBST X: "C:\Documents and Settings\<login>\My Documents\framework"
or in my case:
SUBST X: "D:\Documents\framework"
All the projects then reference absolute paths like
"X:\superio\superio.h" and such.
> The paths to includes have to be constant,
> but the paths to our projects (on our web server) are different -
> some are nested deeper than other.
Use one of the two above suggestions and you won't have to worry about that.
I see what you're trying to do, but I can't think of a reasonable way
to do it, sorry ;-).
> Changing the include paths for each release is no solution.
> The simplest idea is checking out the framework into a subdirectory of each
> project. This worked, now I have a nested working copy in another working
> copy (wc).
> When committing the parent wc, the nested wc is ignored. That's good!
The concept of that sounds very, very bad to me.
Why would you think of a versioned sub-folder in a WC not being
committed as a good thing?
> But unfortunately the nested wc is actually not recognized by Tortoise.
> Rightclicking that folder does only show the default context menu (that for
> all folders). So I cannot commit or update :(
And you're completely sure that it's a checkout and not a export?
Eg. the nested wc does contain a ".svn" folder?
If it really does, it sounds like a bug..
> But when clicking TortoiseSVN->project archive, it directly shows the
> project archive - without querying the URL.
Not sure what you mean.
> Are nested working copies directly supported, but do not work correctly?
> Maybe that feature had been planned but not finished...
I'd say it's a very finished feature.
Basically, any folder versioned by subversioned (= a folder inside a
WC) is in itself a working copy. You have the freedom to move around
these working copy folders in your filesystem as you see fit, and they
will still work as separate working copys containing whatever items
are left in them. Any commit/update on a top folder should affect
subfolders too. (Of course, if you remove a subfolder from inside a
working copy, in that working copy it will count as a 'svn remove' of
the folder and so it might be committed as a removal of a directory..
Can't fully remember, but I think so..)
> ______________________________________________________________
>
> This e-mail may contain confidential and/or privileged information. If you
> are
> not the intended recipient (or have received this e-mail in error) please
> notify
> the sender immediately and destroy this e-mail. Any unauthorised copying,
> disclosure or distribution of the material in this e-mail is strictly
> forbidden.
> ______________________________________________________________
Feel free not to spam public mailing list with disclaimers ;-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed May 18 14:12:56 2005