You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by solo turn <so...@gmail.com> on 2005/06/16 15:52:03 UTC
svk working copy design useable for svn too?
hi,
as the current wc design still causes some headaches, noteably:
* .svn - _svn unusable/difficult for windows development
* .svn unusable for z-os development
* .svn stores ~5-15 files and directories,
which defragments windows filesystems
until they are not useable any more.
* therefor big checkouts
* therefor slow on windows
some of us recently switched to svk and are very happy with it, as it
is clean, fast, offers nice branching, merging.
so i'm wondering if it would be sensible to offer clk's svk working
copy design as second option for a svn working copy design? the client
says then if it would use the traditional one, or clk's.
-solo.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svk working copy design useable for svn too?
Posted by John Peacock <jp...@rowman.com>.
solo turn wrote:
> On 6/16/05, Ben Collins-Sussman <su...@collab.net> wrote:
>>Also, what are the disadvantages of XD?
>
> i'm not sure if there are any. one obvious might be that it uses
> subversions bdb backend which does not run on nfs.
No, you are mistaken. SVK can use whatever FS libraries that Subversion is
compiled with:
$ svk help depotmap
NAME
depotmap - Create or edit the depot mapping configuration
...snip...
Depot creation respects $ENV{SVNFSTYPE}, which is default to fsfs for
svn 1.1 or later, and bdb for svn 1.0.x.
I have stopped compiling in BDB at all on newer installs and SVK works just
fine, thanks! ;-)
> another might be (and this is more a general problem i guess) the
> merging issue bram cohen (codeville) and nathaniel smith (monotone)
> are discussing, saying star merge (as used by svk) is not worth the
> trouble, use codeville merge
Not suprising that the people developing a new algorithm think it is the best
thing to use. I don't even see any mention of star merge in that discussion per
se (unless you are talking about the pathalogical 3-way merges discussed on the
monotone list). I'll let CLKao defend his SVK technique (since this is more
than I can wrap my head around at the moment).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svk working copy design useable for svn too?
Posted by solo turn <so...@gmail.com>.
On 6/16/05, Ben Collins-Sussman <su...@collab.net> wrote:
> Are you volunteering to rewrite all of svk's XD working-copy code in
> C? :-)
there is notes/wc-improvements which does not mention this. so i
wondered if this is deliberately or just nobody put it there ...
there is also the possibility to actively promote svk as svn client
and make it interact better, and get better gui integration for it.
this would prevent rewrite :)
> Also, what are the disadvantages of XD?
i'm not sure if there are any. one obvious might be that it uses
subversions bdb backend which does not run on nfs.
another might be (and this is more a general problem i guess) the
merging issue bram cohen (codeville) and nathaniel smith (monotone)
are discussing, saying star merge (as used by svk) is not worth the
trouble, use codeville merge
(http://thread.gmane.org/gmane.comp.version-control.revctrl/2).
and i have no idea if "weave or delta" storage is directly connected
to this. in http://web.mit.edu/ghudson/thoughts/file-versioning greg
hudson did a good summary a long time ago, this is without mentioning
implications to merging though. but maybe merging and weave/delta
should be discussed in a separate thread.
-solo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svk working copy design useable for svn too?
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 16, 2005, at 10:52 AM, solo turn wrote:
> hi,
>
> as the current wc design still causes some headaches, noteably:
> * .svn - _svn unusable/difficult for windows development
> * .svn unusable for z-os development
> * .svn stores ~5-15 files and directories,
> which defragments windows filesystems
> until they are not useable any more.
> * therefor big checkouts
> * therefor slow on windows
>
> some of us recently switched to svk and are very happy with it, as it
> is clean, fast, offers nice branching, merging.
>
> so i'm wondering if it would be sensible to offer clk's svk working
> copy design as second option for a svn working copy design? the client
> says then if it would use the traditional one, or clk's.
>
Are you volunteering to rewrite all of svk's XD working-copy code in
C? :-)
Also, what are the disadvantages of XD?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org