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 at (no spam) #$% 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.

On Mon, 26 Oct 2009 16:40:09 -0500
Tim Wescott <tim at (no spam) seemywebsite.com> wrote:

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 at (no spam) #$% 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.


If you're running Windows, grab yourself a copy of TortoiseSVN. The
documentation's pretty good, and more importantly, as software it's got
a very high "it just works" factor.

On an unrelated note, the same author's StExBar is one of the things
that makes life under Windows livable.

Rob Gaddi wrote:
On Mon, 26 Oct 2009 16:40:09 -0500
Tim Wescott <t... at (no spam) seemywebsite.com> wrote:

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 at (no spam) #$% 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.

If you're running Windows, grab yourself a copy of TortoiseSVN.  The
documentation's pretty good, and more importantly, as software it's
got a very high "it just works" factor.

On an unrelated note, the same author's StExBar is one of the things
that makes life under Windows livable.

Tim, I'll be the nay sayer here.  I didn't like TortoiseSVN but maybe for
reasons that don't matter to you.  We use SmartSVN because I find it more
similar to Visual SourceSafe.  Compared to Tortoise which is an explorer
integration only (unless it has changed), SmartSVN is both an integration
and a stand alone app. I find it quite user friendly.

On the minus side, SmartSVN isn't free.  You can do a trial for free, but a
license is under $100.

One other note on SVN itself.  If branches are your primary interest, make
sure to follow their recommended (read "required") layouts, i.e., everything
project has its root in \trunk, with parallel \tags and \branch.  I find
this terribly inconvenient for our project format so we don't use it, and
consequently, can not uses tags or branches.

One other note on SVN itself. If branches are your primary interest, make
sure to follow their recommended (read "required") layouts, i.e., everything
project has its root in \trunk, with parallel \tags and \branch. I find
this terribly inconvenient for our project format so we don't use it, and
consequently, can not uses tags or branches.

Not Really Me wrote:

One other note on SVN itself. If branches are your primary interest,
make sure to follow their recommended (read "required") layouts, i.e.,
everything project has its root in \trunk, with parallel \tags and
\branch. I find this terribly inconvenient for our project format so
we don't use it, and consequently, can not uses tags or branches.


Not sure that is the case, although I could be wrong. I thought you
could organise your repository directory structure in any way you like -
when you branch/tag you just have to provide the path to where the
branch/tag is to be stored.

SVN does not draw any distinction between branches and tags, so using
different directories for each allows some organisation to be
maintained. You can have as many directories and sub directories under
the \tags and \branch paths as you like.

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.

On Oct 28, 9:51 am, David Brown <da... at (no spam) westcontrol.removethisbit.com
wrote:
John Devereux wrote:
David Brown <david.br... at (no spam) 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 ?

FreeRTOS info wrote:
Not Really Me wrote:

One other note on SVN itself. If branches are your primary
interest, make sure to follow their recommended (read "required")
layouts, i.e., everything project has its root in \trunk, with
parallel \tags and \branch. I find this terribly inconvenient for
our project format so we don't use it, and consequently, can not
uses tags or branches.

Not sure that is the case, although I could be wrong. I thought you
could organise your repository directory structure in any way you
like - when you branch/tag you just have to provide the path to
where the branch/tag is to be stored.

SVN does not draw any distinction between branches and tags, so using
different directories for each allows some organisation to be
maintained. You can have as many directories and sub directories
under the \tags and \branch paths as you like.


Correct - you can organise things exactly as you see fit. It is quite
reasonable, for example to have something like this:

\mainboard
\trunk
\tags
\release1.00
\release1.01
\branches

\slaveboard
\trunk
\microcontroller
\fpga
\tags
\release1.00
\branches


Organise the directories as you see fit for the project in question.

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.

Tim, I'll be the nay sayer here. I didn't like TortoiseSVN but maybe for
reasons that don't matter to you. We use SmartSVN because I find it more
similar to Visual SourceSafe. Compared to Tortoise which is an explorer
integration only (unless it has changed), SmartSVN is both an integration
and a stand alone app. I find it quite user friendly.

On the minus side, SmartSVN isn't free. You can do a trial for free, but a
license is under $100.

David Brown wrote:
FreeRTOS info wrote:
Not Really Me wrote:

One other note on SVN itself. If branches are your primary
interest, make sure to follow their recommended (read "required")
layouts, i.e., everything project has its root in \trunk, with
parallel \tags and \branch. I find this terribly inconvenient for
our project format so we don't use it, and consequently, can not
uses tags or branches.
Not sure that is the case, although I could be wrong. I thought you
could organise your repository directory structure in any way you
like - when you branch/tag you just have to provide the path to
where the branch/tag is to be stored.

SVN does not draw any distinction between branches and tags, so using
different directories for each allows some organisation to be
maintained. You can have as many directories and sub directories
under the \tags and \branch paths as you like.

Correct - you can organise things exactly as you see fit. It is quite
reasonable, for example to have something like this:

\mainboard
\trunk
\tags
\release1.00
\release1.01
\branches

\slaveboard
\trunk
\microcontroller
\fpga
\tags
\release1.00
\branches


Organise the directories as you see fit for the project in question.

You are all correct, "required" was a mistake. Maybe some of the problem
lies with SmartSVN. It tells me I can not make a tag because I do not have
"trunk"

Due to our layout though, I still don't see a reasonable solution. Let me
give an example. Maybe I don't understand SVN well enough.

\rtos
\core
\docs
\subfolders...
\src
\subfolders...

\port1
\docs
\subfolders...
\src
\subfolders...

\port2
\docs
\subfolders...
\src
\subfolders...

\tcpip
... same as above

FWIW, the subfolders are all 2-3 layers deep.

In an ideal situation I would want to "tag" a product port and have it
include the product core at the same time. Even better, some tags should
span multiple products.

Taking the SmartSVN folks at their word, I would need to have \trunk, \tags,
etc., somewhere. Where would I put them, at the very top level? Doesn't a
tag/branch then make a copy of the entire repository?

Scott

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...

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.

David Brown wrote:
FreeRTOS info wrote:
Not Really Me wrote:

One other note on SVN itself. If branches are your primary
interest, make sure to follow their recommended (read "required")
layouts, i.e., everything project has its root in \trunk, with
parallel \tags and \branch. I find this terribly inconvenient for
our project format so we don't use it, and consequently, can not
uses tags or branches.

In an ideal situation I would want to "tag" a product port and have it
include the product core at the same time. Even better, some tags should

span multiple products.

Taking the SmartSVN folks at their word, I would need to have \trunk,
\tags,
etc., somewhere. Where would I put them, at the very top level? Doesn't
a
tag/branch then make a copy of the entire repository?