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

Re: gcc source management requirements

From: Peter Davis <peter_at_pdavis.cx>
Date: 2002-12-10 04:39:48 CET

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Okay, I think I understand. Instead of simply having the commit fail and then
running "svn update" (or "svn merge") and resolving the conflicts in your
working copy, you want it to create a special branch so that the commit still
succeeds, but isn't actually merged into the HEAD tree. That's an
interesting concept.

Since it is very easy and efficient to create your own branch in Subversion,
you should be able to achieve the same goals, even if Subversion won't
automatically create the branches for you. Personally, I'd even prefer that
I have to make the branches myself, just because I never believe in overly
"smart" tools. I can see how microbranches would be nice coming from CVS
where it is difficult and time- and resource consuming to create branches
manually.

One question: what happens when you've finished merging the various changes in
your microbranch, but someone else has made changes to the HEAD tree and the
microbranch itself becomes out of date? When you commit it, do you get a
micro-microbranch?

I'd hope this wouldn't be an absolute requirement for adoption by GCC or any
other project. It would be a nifty feature, but it just seems like mostly
sugar to me, especially given that one of the other requirements is that
manual branches are quick and easy (and they are with Subversion).

On Monday 09 December 2002 18:58, Robert North wrote:
> Maybe it's something I always look for in version control software, and
> never find:
>
> I often want to be able to commit stuff to the repository.
> The commit is rejected, but I want it to go somewhere in the repository.
> Therefore, the only option is to create a branch from the version you
> checked out, and commit your changes there.
>
> The thing is, I never trust myself to be able to resolve the conflicts
> properly.
>
> I think the idea of branching like this takes the pressure off people,
> they don't have to worry that
> they've deleted the wrong file, or reverted an important merge, just
> because the other
> person was unavailable when a critical decision was made.

- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE99WIEhDAgUT1yirARArL4AJ93NxaVV2tOKPNvG43QKwFHKD8c1ACfUCxY
Fnk51NDLbzdmlOwoJHY2foA=
=mLf6
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 10 04:41:36 2002

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

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