Re: OT: Good SVN How-To?

Tim Wescott <> writes:

> A project I'm working on just shoved me over the threshold from RCS to
> SVN -- I just have to track multiple branches on this one.
>
> But I'm not a version control maven, I'm a @#$% algorithm guy!
>
> Any good SVN "How To's" out there? If O'Reilly has a book I'll probably
> buy it, but a good web-based one that's on the dips**t level (if you want
> to do "A" then type "B") would be nice in the mean time.

I found the main online docs - the "Version Control with Subversion"
book - pretty good.

You might also want to look at git. Blindingly fast, compact and
efficient. It is reputedly very good at managing branches and merges,
even better than svn. No need to setup a server, each copy is its own
repository. Several projects I am familiar with have switched from svn
to git recently (as have I, after using svn for a few years).

Having said that I think you are on windows, where svn could have better
tools. Not sure.


--

John Devereux

John Devereux wrote:
> Tim Wescott <> writes:
>
>> A project I'm working on just shoved me over the threshold from RCS
>> to SVN -- I just have to track multiple branches on this one.
>>
>> But I'm not a version control maven, I'm a @#$% algorithm guy!
>>
>> Any good SVN "How To's" out there? If O'Reilly has a book I'll
>> probably buy it, but a good web-based one that's on the dips**t
>> level (if you want to do "A" then type "B") would be nice in the
>> mean time.
>
> I found the main online docs - the "Version Control with Subversion"
> book - pretty good.
>
> You might also want to look at git. Blindingly fast, compact and
> efficient. It is reputedly very good at managing branches and merges,
> even better than svn. No need to setup a server, each copy is its own
> repository. Several projects I am familiar with have switched from svn
> to git recently (as have I, after using svn for a few years).
>
> Having said that I think you are on windows, where svn could have
> better tools. Not sure.

Ooh, I may have to git that.




__________ Information from ESET NOD32 Antivirus, version of virus signature database 4548 (20091027) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Tim Wescott <> writes:

> On Tue, 27 Oct 2009 08:11:53 +0000, John Devereux wrote:
>
>> Tim Wescott <> writes:
>>
>>> A project I'm working on just shoved me over the threshold from RCS to
>>> SVN -- I just have to track multiple branches on this one.
>>>
>>> But I'm not a version control maven, I'm a @#$% algorithm guy!
>>>
>>> Any good SVN "How To's" out there? If O'Reilly has a book I'll
>>> probably buy it, but a good web-based one that's on the dips**t level
>>> (if you want to do "A" then type "B") would be nice in the mean time.
>>
>> I found the main online docs - the "Version Control with Subversion"
>> book - pretty good.
>>
>> You might also want to look at git. Blindingly fast, compact and
>> efficient. It is reputedly very good at managing branches and merges,
>> even better than svn. No need to setup a server, each copy is its own
>> repository. Several projects I am familiar with have switched from svn
>> to git recently (as have I, after using svn for a few years).
>>
>> Having said that I think you are on windows, where svn could have better
>> tools. Not sure.
>
> What, just because I don't spell it "Windoze" or "Micro$oft" you think
> I'm on Windows? It's a mixed-religion household, with both Linux and
> Windows boxes (mine are all Linux).

Sorry, I must have misremembered. Maybe it was Joerg.

> The server is on a Linux box, but the primary users are on Vista.

OK, never looked into the windows client support. (Could well be be
excellent too, but not looked myself)..

--

John Devereux

David Brown <> writes:

> David Kelly wrote:
>> John Devereux wrote:
>>>
>>> You might also want to look at git. Blindingly fast, compact and
>>> efficient. It is reputedly very good at managing branches and merges,
>>> even better than svn. No need to setup a server, each copy is its own
>>> repository. Several projects I am familiar with have switched from svn
>>> to git recently (as have I, after using svn for a few years).
>>
>> svn does not require a server. Specify your repository as file:///
>>
>>> Having said that I think you are on windows, where svn could have better
>>> tools. Not sure.
>>
>> IMO a major flaw in the way many Windows people think is that they
>> will run svn in client-fileserver mode (using file:/// as mentioned
>> above on a shared volume) rather than client-svnserver.
>>
>> In client-fileserver every user must have full permissions on the
>> repository, including the metadata. IMO this is asking for trouble,
>> especially if there are multiple simultaneous users.
>
> This is, AFAIK, /exactly/ how MS Source Safe works - and is, AFAIK,
> the biggest single reason for its terrible reputation.
>
> Using file:/// is good for a single developer on their own machine -
> it makes it easy to track changes and old code. But if you want to
> share the repository with others, then (as you say) you really ought
> to use a proper server. Both svnserve and webdav are easy to set up
> on a server.

Of course most people use git with a server too. I meant that you don't
*have* to, and I think you can do a lot more when without server access.


--

John Devereux

John Devereux wrote:
> David Brown <> writes:
>
>> David Kelly wrote:
>>> John Devereux wrote:
>>>> You might also want to look at git. Blindingly fast, compact and
>>>> efficient. It is reputedly very good at managing branches and merges,
>>>> even better than svn. No need to setup a server, each copy is its own
>>>> repository. Several projects I am familiar with have switched from svn
>>>> to git recently (as have I, after using svn for a few years).
>>> svn does not require a server. Specify your repository as file:///
>>>
>>>> Having said that I think you are on windows, where svn could have better
>>>> tools. Not sure.
>>> IMO a major flaw in the way many Windows people think is that they
>>> will run svn in client-fileserver mode (using file:/// as mentioned
>>> above on a shared volume) rather than client-svnserver.
>>>
>>> In client-fileserver every user must have full permissions on the
>>> repository, including the metadata. IMO this is asking for trouble,
>>> especially if there are multiple simultaneous users.
>> This is, AFAIK, /exactly/ how MS Source Safe works - and is, AFAIK,
>> the biggest single reason for its terrible reputation.
>>
>> Using file:/// is good for a single developer on their own machine -
>> it makes it easy to track changes and old code. But if you want to
>> share the repository with others, then (as you say) you really ought
>> to use a proper server. Both svnserve and webdav are easy to set up
>> on a server.
>
> Of course most people use git with a server too. I meant that you don't
> *have* to, and I think you can do a lot more when without server access.
>

git works by having a local copy of the repository (either all of it, or
just the parts you are interested in). So you can do your work against
your local copy, including check ins and check outs, and then later push
some of your changes to a remote server for others to see. My
understanding is that it is good at handling lots of variants in the
code with different patches, and being decentralised makes it better for
when you can't always be in close contact with a main server.

svn, on the other hand, is based on the idea of a central server that is
the master and holds all the revisions. Most operations therefore need
contact with the server. Since your revisions are all in one place, it
is much easier to keep an overview - you have a mostly linear
progression (branching and merging can be viewed as non-linear operations).

The two systems each have their place, and their advantages and
disadvantages. git is ideal for the Linux kernel development model
(oddly enough), while svn is normally a better match for a development
team in one (or a few) location.

On Oct 28, 9:51*am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> John Devereux wrote:
> > David Brown <david.br...@hesbynett.removethisbit.no> writes:
>
> >> David Kelly wrote:
> >>> John Devereux wrote:
> >>>> You might also want to look at git. Blindingly fast, compact and
> >>>> efficient. It is reputedly very good at managing branches and merges,
> >>>> even better than svn. No need to setup a server, each copy is its own
> >>>> repository. Several projects I am familiar with have switched from svn
> >>>> to git recently (as have I, after using svn for a few years).
> >>> svn does not require a server. Specify your repository as file:///
>
> >>>> Having said that I think you are on windows, where svn could have better
> >>>> tools. Not sure.
> >>> IMO a major flaw in the way many Windows people think is that they
> >>> will run svn in client-fileserver mode (using file:/// as mentioned
> >>> above on a shared volume) rather than client-svnserver.
>
> >>> In client-fileserver every user must have full permissions on the
> >>> repository, including the metadata. IMO this is asking for trouble,
> >>> especially if there are multiple simultaneous users.
> >> This is, AFAIK, /exactly/ how MS Source Safe works - and is, AFAIK,
> >> the biggest single reason for its terrible reputation.
>
> >> Using file:/// is good for a single developer on their own machine -
> >> it makes it easy to track changes and old code. *But if you want to
> >> share the repository with others, then (as you say) you really ought
> >> to use a proper server. *Both svnserve and webdav are easy to set up
> >> on a server.
>
> > Of course most people use git with a server too. I meant that you don't
> > *have* to, and I think you can do a lot more when without server access..
>
> git works by having a local copy of the repository (either all of it, or
> just the parts you are interested in). *So you can do your work against
> your local copy, including check ins and check outs, and then later push
> some of your changes to a remote server for others to see. *My
> understanding is that it is good at handling lots of variants in the
> code with different patches, and being decentralised makes it better for
> when you can't always be in close contact with a main server.
>
> svn, on the other hand, is based on the idea of a central server that is
> the master and holds all the revisions. *Most operations therefore need
> contact with the server. *Since your revisions are all in one place, it
> is much easier to keep an overview - you have a mostly linear
> progression (branching and merging can be viewed as non-linear operations).
>
> The two systems each have their place, and their advantages and
> disadvantages. *git is ideal for the Linux kernel development model
> (oddly enough), while svn is normally a better match for a development
> team in one (or a few) location.

does git use the Copy-Modify-Merge or Lock-Modify-Unlock Solution ?

bigbrownbeastie wrote:
> On Oct 28, 9:51 am, David Brown <da...@westcontrol.removethisbit.com>
> wrote:
>> John Devereux wrote:
>>> David Brown <david.br...@hesbynett.removethisbit.no> writes:
>>>> David Kelly wrote:
>>>>> John Devereux wrote:
>>>>>> You might also want to look at git. Blindingly fast, compact and
>>>>>> efficient. It is reputedly very good at managing branches and merges,
>>>>>> even better than svn. No need to setup a server, each copy is its own
>>>>>> repository. Several projects I am familiar with have switched from svn
>>>>>> to git recently (as have I, after using svn for a few years).
>>>>> svn does not require a server. Specify your repository as file:///
>>>>>> Having said that I think you are on windows, where svn could have better
>>>>>> tools. Not sure.
>>>>> IMO a major flaw in the way many Windows people think is that they
>>>>> will run svn in client-fileserver mode (using file:/// as mentioned
>>>>> above on a shared volume) rather than client-svnserver.
>>>>> In client-fileserver every user must have full permissions on the
>>>>> repository, including the metadata. IMO this is asking for trouble,
>>>>> especially if there are multiple simultaneous users.
>>>> This is, AFAIK, /exactly/ how MS Source Safe works - and is, AFAIK,
>>>> the biggest single reason for its terrible reputation.
>>>> Using file:/// is good for a single developer on their own machine -
>>>> it makes it easy to track changes and old code. But if you want to
>>>> share the repository with others, then (as you say) you really ought
>>>> to use a proper server. Both svnserve and webdav are easy to set up
>>>> on a server.
>>> Of course most people use git with a server too. I meant that you don't
>>> *have* to, and I think you can do a lot more when without server access.
>> git works by having a local copy of the repository (either all of it, or
>> just the parts you are interested in). So you can do your work against
>> your local copy, including check ins and check outs, and then later push
>> some of your changes to a remote server for others to see. My
>> understanding is that it is good at handling lots of variants in the
>> code with different patches, and being decentralised makes it better for
>> when you can't always be in close contact with a main server.
>>
>> svn, on the other hand, is based on the idea of a central server that is
>> the master and holds all the revisions. Most operations therefore need
>> contact with the server. Since your revisions are all in one place, it
>> is much easier to keep an overview - you have a mostly linear
>> progression (branching and merging can be viewed as non-linear operations).
>>
>> The two systems each have their place, and their advantages and
>> disadvantages. git is ideal for the Linux kernel development model
>> (oddly enough), while svn is normally a better match for a development
>> team in one (or a few) location.
>
> does git use the Copy-Modify-Merge or Lock-Modify-Unlock Solution ?

I don't know - I only know what I have read about git, having considered
it for our own use. But I concluded that svn fitted our needs better,
so there is a limit to my knowledge of its technical details. However,
I'd guess that there is not much in the way of locking involved -
anything with locks would have trouble scaling to fit the needs of the
Linux kernel developers.

Hopefully someone else can give you a more qualified answer.

On Oct 29, 12:58*pm, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> bigbrownbeastie wrote:
> > On Oct 28, 9:51 am, David Brown <da...@westcontrol.removethisbit.com>
> > wrote:
> >> John Devereux wrote:
> >>> David Brown <david.br...@hesbynett.removethisbit.no> writes:
> >>>> David Kelly wrote:
> >>>>> John Devereux wrote:
> >>>>>> You might also want to look at git. Blindingly fast, compact and
> >>>>>> efficient. It is reputedly very good at managing branches and merges,
> >>>>>> even better than svn. No need to setup a server, each copy is its own
> >>>>>> repository. Several projects I am familiar with have switched fromsvn
> >>>>>> to git recently (as have I, after using svn for a few years).
> >>>>> svn does not require a server. Specify your repository as file:///
> >>>>>> Having said that I think you are on windows, where svn could have better
> >>>>>> tools. Not sure.
> >>>>> IMO a major flaw in the way many Windows people think is that they
> >>>>> will run svn in client-fileserver mode (using file:/// as mentioned
> >>>>> above on a shared volume) rather than client-svnserver.
> >>>>> In client-fileserver every user must have full permissions on the
> >>>>> repository, including the metadata. IMO this is asking for trouble,
> >>>>> especially if there are multiple simultaneous users.
> >>>> This is, AFAIK, /exactly/ how MS Source Safe works - and is, AFAIK,
> >>>> the biggest single reason for its terrible reputation.
> >>>> Using file:/// is good for a single developer on their own machine -
> >>>> it makes it easy to track changes and old code. *But if you want to
> >>>> share the repository with others, then (as you say) you really ought
> >>>> to use a proper server. *Both svnserve and webdav are easy to set up
> >>>> on a server.
> >>> Of course most people use git with a server too. I meant that you don't
> >>> *have* to, and I think you can do a lot more when without server access.
> >> git works by having a local copy of the repository (either all of it, or
> >> just the parts you are interested in). *So you can do your work against
> >> your local copy, including check ins and check outs, and then later push
> >> some of your changes to a remote server for others to see. *My
> >> understanding is that it is good at handling lots of variants in the
> >> code with different patches, and being decentralised makes it better for
> >> when you can't always be in close contact with a main server.
>
> >> svn, on the other hand, is based on the idea of a central server that is
> >> the master and holds all the revisions. *Most operations therefore need
> >> contact with the server. *Since your revisions are all in one place,it
> >> is much easier to keep an overview - you have a mostly linear
> >> progression (branching and merging can be viewed as non-linear operations).
>
> >> The two systems each have their place, and their advantages and
> >> disadvantages. *git is ideal for the Linux kernel development model
> >> (oddly enough), while svn is normally a better match for a development
> >> team in one (or a few) location.
>
> > does git use the Copy-Modify-Merge *or Lock-Modify-Unlock Solution ?
>
> I don't know - I only know what I have read about git, having considered
> it for our own use. *But I concluded that svn fitted our needs better,
> so there is a limit to my knowledge of its technical details. *However,
> I'd guess that there is not much in the way of locking involved -
> anything with locks would have trouble scaling to fit the needs of the
> Linux kernel developers.
>
> Hopefully someone else can give you a more qualified answer.

go and read the svn book (above) and it explains in the first chapter
or so.

David Brown wrote:
>
>
> Using file:/// is good for a single developer on their own machine - it
> makes it easy to track changes and old code. But if you want to share
> the repository with others, then (as you say) you really ought to use a
> proper server. Both svnserve and webdav are easy to set up on a server.

I've been looking into svn, as a client uses Tortoise for their
projects. It's easy to use, but I generally prefer standalone apps over
explorer extensions of any kind.

If you are choosing the client server route, which is the plan here
using the lab server, you need to consider which model to use. The http
server model needs hundreds of Mb of dependencies installed to make it
work, including Apache and the setup looks far from trivial. Usefull if
you want to run it over the net, but there's an alternate model that
ends up as not much more than a compact standalone daemon at the server
end. More usefull for someone who just needs to make it work, rather
than get immersed in the internals...

Regards,

Chris

David Brown wrote:

>
> I'm not sure how many "hundreds of Mb" of dependencies are needed for
> serving svn via apache, but the setup is not that hard (at least, if
> you've done some apache installation and configuration before). The
> svnserve route is certainly lighter in terms of setup and resources,
> while serving via apache is more flexible. If you need a web server
> anyway (such as for trac), if you need tighter security on parts of the
> repository, or if you want to do things like redirections or name-based
> virtual serving, go for apache. If you want a simple light server, go
> for svnserve. You have a choice - I've used both.

That's a pretty good summary. The lab server is only used for a few
local machines and will never be exposed it to the web. A lightweight
solution seems to be more appropriate. I just want to be able to use svn
and don't have the time to spend days doing configuration of unrelated
applications.

If there were a need for a webserver, would most likely export the
server directory read only and have another bare bones linux machine as
web server, perhaps ipcop or similar, with the directory nfs mounted...

Regards,

Chris