On Mon, Jun 8, 2009 at 3:00 PM, Oto BREZINA <otik_at_e-posta.sk> wrote:
> Dear all,
>
> Would be a good UI. But a hell lot of work since there are no suitable
> standard controls to use here.
> And I'm not sure if it's worth the work for something most users will
> never even use.
>
>
> Not sure if worthy, but at least used, in our project layout is sometimes
> (rare, but it happen) good to checkout 2-3 folders from 5+. We either get
> them all and waste disk space, or make 3 checkout. Sometime may happen that
> multiple checkout this choice was not best. Lead to multiple commit (in good
> designed repository this should probably not happen, in real world it is
> very rare).
> Other point is that we have some common documentation near modules, so
> switching some folder off may be nice, but this may be handled by other
> workaround when really needed (e. g. delete and add to ignore list) - never
> used till now:)
>
> While I see this interseting, there are also questions about handling some
> situations. I expect that svn does not support this native, so even update
> and commit may by intersting to handle. Also which log messages should be
> shown for such checkout is not clear for me.
> What about each file separately ?
>
> I think that this sound nice, but I see more "problems" than gain for a
> moment.
>
> Stefan
>
>
> Oto
>
Oto,
Subversion has a feature called sparse directories which allows a working
copy to only checkout a small portion of the repository. This UI design I'm
suggesting directly takes advantage of those features. There is no special
tortoiseSVN implementation that makes this kind of sparse checkout possible.
But even having said that, it is still a bit of work to design the UI and
get the layout done in such a way that it would be ideal. So it will still
be a lot of work.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2360464
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-06-08 23:10:14 CEST