Hi,
I understand the multiple checkin problem that would arise, let the multiple
checkout feature be implemented.
But that problem wouldn't be hard to manage as each subfolder checkouted
would have a reference to it's repository path, so
you could have multiple folder selected, and do a multiple folder commit
from inside the top folder.
I have considered a common layout, in fact, the layout I'm using is quite
well organized, and is a choice, from
not only me, but from a bunch of senior analysts, knowing how subversion
works, and up to where we can reorganize
our projects so as to fit our needs.
Of course, it would be really nice to refactor the projects to have them
ready in a single checkout as you say it, but this just
can't be done, there are too many projects to migrate (>120), there are
other infrastructure considerations which do not allow
us to have a single folder containing everything (aside from the top
repository location), and even if we could reorganize the projects,
we haven't got the time/money to reorganize things that much anyways (you'll
understand big companies constraints).
It is obvious that I can manage to checkout the projects as I want them not
using TSVN, scripting it, using svn command line and
ant or whatever, but It would be a tremendous time saving to have that
feature implemented, so that new developpers can just fetch the projects
they want, in the folder they want, not having to pop the dialog 3-4 times,
and I don't think creating nested layouts would necessarily render the
repositories obsolete, and even if users want to do so, it would be their
problem to manage in the end.
I know you might not care, but I have checked the eclipse plugin for
subversion, subclipse, and he is able to do so, selecting
multiple folders from the repository, and selecting checkout as project
actually checkouts those folders as if they were projects locally,
in the same folder, even if they're not siblings in the repository.
Thank you for taking time to answer my remarks,
--Peter.
On 4/26/06, Stefan Küng <tortoisesvn@gmail.com> wrote:
>
> Peter Scmsvn wrote:
> > Hi,
> >
> > aside from the "clean" layout argument, is there any known performance
> > issue when using extra folders organization in SVN ?
>
> Performance? No.
> But you can't commit the whole project anymore by right-clicking on the
> top folder. Sure, the commit dialog will warn you if you have
> modifications inside a folder which doesn't belong to the repository,
> but it won't (can't) commit them.
>
> > Does the level where the branches/tags/trunk folder is located has any
> > importance, as long as it is consistent with each project's architecture
> > ? Having read that they were optional, I would doubt so.
>
> No, you can choose whatever names and layout you want. But of course,
> people are used to see trunk/branches/tags and know what they represent.
> So if you choose not to use those, people might not know immediately
> what your folders are there for, where to look for releases, ...
>
> > I really don't want to enter "religious" discussions about repositories
> > layouts, but wouldn't it be a better idea to leave that choice to the
> > end-user who might (as I am) be constrained to certain infrastructure
> > concerns, while giving the most features possible so as to make the job
> > easier ?
>
> Sure. But you should also consider that following a 'common layout' has
> many benefits too. Maybe it would need only little tweaks to your
> project to adjust it to that layout.
>
> > You also refer to repository creation, but for instance I'm actually
> > migrating existing projects from another SCS, which doesn't quite let me
> > the freedom to refactor every project, to "clean" them...
> > I think I might not be alone in that case.
>
> Subversion lets you move folders and rename them. You can reorganize the
> project after the conversion.
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.tigris.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
> For additional commands, e-mail: users-help@tortoisesvn.tigris.org
>
>
Received on Wed Apr 26 14:58:40 2006