struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <mart...@apache.org>
Subject Re: SOURCEFORGE.NET UPDATE - 2006-02-24 EDITION
Date Sat, 25 Feb 2006 23:06:25 GMT
On 2/25/06, Leon Rosenberg <rosenberg.leon@googlemail.com> wrote:
>
> To Quote from the link:
> But wait a moment: isn't this tag-creation procedure the same
> procedure we used to create a branch? Yes, in fact, it is. In
> Subversion, there's no difference between a tag and a branch. Both are
> just ordinary directories that are created by copying. Just as with
> branches, the only reason a copied directory is a "tag" is because
> humans have decided to treat it that way: as long as nobody ever
> commits to the directory, it forever remains a snapshot. If people
> start committing to it, it becomes a branch.
>
> Allow me to explain we work, and why we feel, that this tagging isn't
> sufficent.


I can't stop you - it's a public mailing list. ;-) However, how you feel
about tagging and source control systems really has nothing at all to do
with Struts development. I would suggest that you take your issues up on the
SVN mailing lists, if you care to discuss how SVN could meet your needs.

--
Martin Cooper


We make releases of the prod system twice a month, 95% of them aren't
> head releases.
> What we do is to assign a Tag to each project. There are two projects
> always existing:
> bugfixes+tasks and improvements. Lets say the bugfix project has the
> tag "romeo" and improvements: "julia". We would then have some
> projects running by different people, which are larger then just a
> "task" and become own tags. Lets say we have 3 projects running, yago,
> ophelia and fontibras. No we decide to make release r25. We notice
> that project yago isn't yet release ready, and will be released in
> r26. To create r25 we check out r24, then checkout julia, romeo,
> ophelia and fontibras into this tree and tag the result as r25. Note
> that same files can have all project tags (for example the
> struts-config.xmls are good candidates) on same version, or on
> different versions, which is then resolved by the build scripts.
> Further, the last version of each file which was built to the
> testsystem has a 'test' tag, and the last version of each file which
> was built to  the prod system, has the tag "live". All release and
> project tags are persistent, we don't remove them, until the file is
> deleted (which is performed by tagging the file "todelete", but thats
> a different story :-))
>
> I don't see how we can get this to work with "copying"... But maybe
> you could help me a bit? At least I didn't found anything in your urls
> or in my previous searching the net...
>
> http://www.pushok.com/soft_svn_vscvs.php
>
> also states that there is no tagging (in my and probably his/her
> understanding of tagging of course) in svn...
>
> regards
> Leon
>
>
>
> On 2/25/06, Martin Cooper <martinc@apache.org> wrote:
> > On 2/25/06, Leon Rosenberg <rosenberg.leon@googlemail.com> wrote:
> > >
> > > just out of interest, why is svn better than cvs? I mean the only
> > > difference I see by now, is missing support for tagging in svn, but
> > > what are the benefits? :-)
> >
> >
> > You must not be looking very hard. ;-) SVN has tagging support; it
> wouldn't
> > be much of a source control system without it. See:
> >
> > http://svnbook.red-bean.com/en/1.1/ch04s06.html
> >
> > That book also has a good summary of why SVN is better than CVS. See:
> >
> > http://svnbook.red-bean.com/en/1.1/ch01s03.html
> >
> > My two favourite features of SVN are atomic commits and remote
> operations,
> > neither of which CVS supports. The former is described in the chapter
> > referenced above. The latter means that I can do things like tagging and
> > branching directly within the repository, without having to have a
> checked
> > out copy.
> >
> > Another reason the ASF likes SVN is because, unlike CVS, it's not tied
> to
> > Unix accounts, which allows a more secure system.
> >
> > Take a closer look at the book referenced above. There is a *lot* to
> like
> > about SVN. Many of us here were initially reluctant to move from CVS to
> SVN,
> > but pretty much as soon as we did, we all started talking about how we
> > couldn't live without it. :-)
> >
> > --
> > Martin Cooper
> >
> >
> > thanx
> > > leon
> > >
> > > On 2/25/06, James Mitchell <jmitchell@apache.org> wrote:
> > > > Some interesting news from sf.net.  They now offer SVN...cool!
> > > >
> > > > --
> > > > James Mitchell
> > > > EdgeTech, Inc.
> > > > http://edgetechservices.net/
> > > > 678.910.8017
> > > > Skype: jmitchtx
> > > >
> > > >
> > > >
> > > > Begin forwarded message:
> > > >
> > > > <snip/>
> > > > >
> > > > > Subversion General Availability
> > > > > -------------------------------
> > > > >
> > > > > The SourceForge.net team is pleased to announce the General
> > > > > Availability
> > > > > of Subversion service to SourceForge.net-hosted projects,
> effective
> > > > > 2006-02-21. This service offering is in addition to our existing
> CVS
> > > > > service; as with all of our services, projects may select (and
> > > > > enable in
> > > > > the project admin pages) the portion of our offering that best
> meets
> > > > > their needs.
> > > > >
> > > > > We wish to extend our thanks to the many projects and developers
> who
> > > > > have helped us to test our Subversion service as part of our
> six-week
> > > > > beta, which completed last week. Our particular thanks go to these
> > > > > projects, whose members provided substantial feedback regarding
> the
> > > > > new service:
> > > > >
> > > > > * Inkscape - http://sourceforge.net/projects/inkscape/
> > > > > * DejaVu Fonts - http://sourceforge.net/projects/dejavu/
> > > > > * ScummVM - http://sourceforge.net/projects/scummvm/
> > > > > * evilnet - http://sourceforge.net/projects/evilnet/
> > > > >
> > > > >
> > > > > Our Subversion service includes:
> > > > >
> > > > > SSL-based Repository Access:
> > > > > * Developer Subversion access via HTTPS, auth is requested when
> you
> > > > > perform a write operation
> > > > > * Anonymous Subversion access via HTTPS
> > > > > * No sync delays between developer and anonymous Subversion access
> > > > > * Per-developer access control over repository access (ACL support
> > > > > to be
> > > > > added in the future) via the SourceForge.net permissions system
> > > > >
> > > > > Web-based viewing:
> > > > > * Web-based repository access via ViewVC (formerly known as
> ViewCVS)
> > > > >
> > > > > On-demand self-service backups and mirroring capability:
> > > > > * Read-only rsync access to the repository to permit backups and
> > > > > remote mirroring
> > > > >
> > > > > Ease of migration:
> > > > > * Automated self-service migration of your SourceForge.net project
> CVS
> > > > > repository, CVS tarball, or Subversion dump to our Subversion
> service
> > > > >
> > > > > Well-considered add-ons to basic service:
> > > > > * A selected set of hook scripts, including commit email support
> and
> > > > > CIA bot support
> > > > > * Statistics tracking of Subversion repository activity
> > > > >
> > > > >
> > > > > Service may be enabled by project administrators in the
> "Subversion"
> > > > > section of the Project Admin pages.
> > > > >
> > > > > Complete service documentation is available at:
> > > > > http://sf.net/docs/E09/
> > > > >
> > > > > Documentation is provided for supported clients at:
> > > > > http://sf.net/docs/F06/ for the command-line SVN client
> > > > > http://sf.net/docs/F07/ for TortoiseSVN
> > > > >
> > > > > Our support of Subversion has been based on substantial research
> and
> > > > > testing in the past few months, which we have pursued specifically
> > > > > based
> > > > > on requests from the community. SourceForge.net continues to
> consider
> > > > > new technologies and evaluate community requests in further
> > > > > strengthening our service offering.
> > > > >
> > > > >
> > > > <snip/>
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > > For additional commands, e-mail: dev-help@struts.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message