[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Checking on SVN Feature

From: Ryan Schmidt <subversion-2005_at_ryandesign.com>
Date: 2005-10-07 13:53:43 CEST

On Oct 7, 2005, at 12:26, Thyagarajan Krishnan wrote:

> 1. Is there a baselining concept present in SVN? If not how i
> could achieve in a different way?

I don't know what "baselining" is. Can you explain in more detail
what you need?

> 2. SVN follows update-modify-merge model - i see this has
> immediate workflow as the code is not validated by a BM. As a
> version control tool this is just enough. But we have a slightly
> different requirement and wanted to extend the functionality bit more.
> Lets say if i wanted to implement a process where the BM checks all
> checked-in versions before the revisions are visible to others?
> also a process where the Deverlopers gets only the validated code
> from the BM? How to ensure this with SVN?

You can dictate that developers check code into their own private
branches, then inform the BM who checks the code and, once it's
approved, merges it into the trunk. The disadvantage is the overhead
for the developers of keeping their private branches up-to-date (by
routinely merging changes back in from the trunk; this is currently a
manual process in which you have to keep track of revision numbers)
and that the log of the trunk will only show commits by the BM. (The
BM would have to write into his commit message from whom the code
originally came, in what revision, in what branch, so you could later
use that info to go back and look at the developer's original commit
message if needed.) The BM will also have to deal with any merge
conflicts, which, depending on several factors, could be bothersome.

> 3. Is there a way where i can specify the lifecycle for the souces??

What does this mean?

Subversion merely stores stuff you check in. If you check it in, it's
there forever [1]. If you don't check it in, it's not there.

[1] You can delete information from a respository afterwards, but
it's a cumbersome procedure of dumping the repository to a text file,
filtering out the parts you don't want, and then reimporting the
filtered file into a new repository, during which time nobody can be
accessing the repository of course. It's intentional that it's not
easy to do, as it's a direct contradiction of Subversion's design
philosophy as a revision control system, which is that all data be
kept for all time.

> 4. Our installation includes apache, so the repos can be browsed
> from the Web. Would like to know is there a possibility of doing
> version control activities from the Web Client? If yes pls provide
> me some info.

The built-in ability Subversion has to be browsed by the web exists
mostly as an accident, and doesn't have any features other than
looking at the HEAD revision. You cannot modify anything, and you
cannot look at older revisions. It's not intended to be used for
those tasks. There are a variety of other web interfaces to
Subversion repositories which have more features. ViewCVS, WebSVN and
Trac come to mind. There's also Svn Manager, which I believe has a
different focus (letting you do administrative, rather than user-
oriented, tasks).

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 7 13:55:53 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.