> How long does it take to delete a directory and its contents? You
> wouldn't even have to recheck the files out:
>
> svn co https://svn/project
>
> oops
>
> mv project/trunk project-trunk
> rm -rf project
> mv project-trunk project
We were talking about a bit different scenario:
mv project1/trunk project1-trunk
rm -rf project1
mv project2/trunk project2-trunk
rm -rf project2
mv project3/trunk project3-trunk
rm -rf project3
mv project4/trunk project4-trunk
rm -rf project4
mv project5/trunk project5-trunk
rm -rf project5
(... repeat for other 243 modules ...)
> > How do you check out next fresh working copy?
>
> svn co https://svn/project/trunk project
>
> >Do you check out each module separately?
>
> Yes.
And that's the problem for me (pointed out where the discussion about
this problem started). My repository (and probably any typical
repository for software development company) contains a lot of project,
subproject, libraries, modules etc.
>
> > What about updating?
>
> svn up
>
> You do realize you can nest a working copy within another working copy?
> You'll have to run your updates separately but if they're separte
> projects isn't that what you want anyway?
Usually no. For instance currently I am developing some application,
using and sometimes patching 23 general-use libraries prepared inhouse
in my company, 8 project specific libraries and a few modules into which
the application is splitted. When working on top-new version I usually
want to update everything to use fresh version of libraries code. Of
course commits are performed locally, similarly tagging.
> > Maybe. But seems to me, it would be more natural NOT to checkout all the
> > tags by default and give -I_know_what_I_am_doing switch for those rare
> > cases where someone really wants to do that.
>
> subversion doesn't know what a tag is.
And here is where the whole discussion started.
> How you use a path in your repo is what matters.
> In order to get what
> you want here would force us to force everyone into a set of repository
> layouts or make the design more
> complex for something that frankly isn't really much of a problem.
I do not think that tags or labels are something exotic, not usually met
in version control tools. And I know at least one tool which -
possessing 'copy' mechanism similar to possessed by subversion - added
labeling mechanism too (Perforce).
The mentioned by you freedom of choosing paths in repo has also second
face: creating tags and branches is and will be harder in subversion
than in other tools (no way to say 'I want to create tag xxxx in the
current directory' - I need to specify where this tag is to lie in
repository, using GUI it means some extra window and path selector).
In my opinion, subversion 'tags directories' are in fact branches.
Fairly nice branches. One can try to workaround the lack of tags using
branches for tagging, but it is not the best solution.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 3 02:35:23 2004