You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by sam th <sa...@uchicago.edu> on 2002/12/10 01:44:05 UTC
gcc source management requirements
In a discussion with Tom Lord on the GCC list, Zack Weinberg [1] posted
an excellent list of requirements for a source control system. Some of
them are for the future, some of them are requirements for anything that
wants to replace CVS. They're worth taking a look at. [2]
http://gcc.gnu.org/ml/gcc/2002-12/msg00444.html
[1] Who I know is on this list, but hasn't mentioned his list on this
list. Hope I'm not stepping on your toes, Zack.
[2] It should be noted that SVN fails requirement 0. Hopefully the APR
people consider this an issue as well.
--
sam th <sa...@uchicago.edu>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by rb...@apache.org.
On 9 Dec 2002, sam th wrote:
> On Mon, 2002-12-09 at 22:58, Ryan Bloom wrote:
> > As Justin already stated, APR does work on QNX. To the best of my knowledge
> > it will work on LynxOS and Unicos/Mk, although that is conjecture based on
> > how APR works. As for VMS, my understanding is that
> > Digital....Compaq......HP have actually ported APR to VMS already.
> > Regardless, getting a port to those platforms will be trivial if it doesn't
> > already work. All that needs to happen, is somebody needs to do the port.
> > If anybody can get me access to any or all of those platforms, I would be
> > more than happy to help.
>
> Wonderful. I'm happy to be proved wrong.
Sorry, re-reading the message I sound very defensive. I created the
initial design for APR, so I really don't like hearing that we aren't as
portable as we could be. :-)
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by sam th <sa...@uchicago.edu>.
On Mon, 2002-12-09 at 22:58, Ryan Bloom wrote:
> As Justin already stated, APR does work on QNX. To the best of my knowledge
> it will work on LynxOS and Unicos/Mk, although that is conjecture based on
> how APR works. As for VMS, my understanding is that
> Digital....Compaq......HP have actually ported APR to VMS already.
> Regardless, getting a port to those platforms will be trivial if it doesn't
> already work. All that needs to happen, is somebody needs to do the port.
> If anybody can get me access to any or all of those platforms, I would be
> more than happy to help.
Wonderful. I'm happy to be proved wrong.
--
sam th <sa...@uchicago.edu>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Ryan Bloom <rb...@covalent.net>.
On Monday 09 December 2002 06:47 pm, sam th wrote:
> On Mon, 2002-12-09 at 19:58, Ryan Bloom wrote:
> > On Monday 09 December 2002 05:44 pm, sam th wrote:
> > > [2] It should be noted that SVN fails requirement 0. Hopefully the APR
> > > people consider this an issue as well.
> >
> > APR is being used in Apache 2.0 currently, and currently works on: Every
> > known version of Unix, Windows(all versions), Mac OS X, OS/2, BeOS,
> > OS/390, and AS/400. What platforms are we missing?
>
> For example, APR doesn't, to my knowledge, work on QNX. That's just off
> the top of my head, since AbiWord does work on QNX, and we'd need a port
> to move to SVN.
>
> For other examples, the GCC web page [1] lists such operating systems as
> Unicos/Mk, or LynxOS, which I don't think APR has been ported to. Or
> Unos (which I couldn't even find in google). Or, to be really evil,
> people mention VMS occasionally on gcc lists. The port at least used to
> work (I think).
As Justin already stated, APR does work on QNX. To the best of my knowledge
it will work on LynxOS and Unicos/Mk, although that is conjecture based on
how APR works. As for VMS, my understanding is that
Digital....Compaq......HP have actually ported APR to VMS already.
Regardless, getting a port to those platforms will be trivial if it doesn't
already work. All that needs to happen, is somebody needs to do the port.
If anybody can get me access to any or all of those platforms, I would be
more than happy to help.
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Justin Erenkrantz <je...@apache.org>.
--On Monday, December 9, 2002 8:47 PM -0600 sam th <sa...@uchicago.edu>
wrote:
> For example, APR doesn't, to my knowledge, work on QNX. That's
> just off the top of my head, since AbiWord does work on QNX, and
> we'd need a port to move to SVN.
No, that's not true. Someone submitted a small patch to APR to
support QNX 6 over a year ago (only code change was to switch
'ushort' to 'unsigned short' in a private header file). AFAIK, it
still works, but I don't use QNX. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Daniel Berlin <db...@dberlin.org>.
On Monday, December 9, 2002, at 09:47 PM, sam th wrote:
> On Mon, 2002-12-09 at 19:58, Ryan Bloom wrote:
>> On Monday 09 December 2002 05:44 pm, sam th wrote:
>>>
>>> [2] It should be noted that SVN fails requirement 0. Hopefully the
>>> APR
>>> people consider this an issue as well.
>
>> APR is being used in Apache 2.0 currently, and currently works on:
>> Every
>> known version of Unix, Windows(all versions), Mac OS X, OS/2, BeOS,
>> OS/390,
>> and AS/400. What platforms are we missing?
>
> For example, APR doesn't, to my knowledge, work on QNX. That's just
> off
> the top of my head, since AbiWord does work on QNX, and we'd need a
> port
> to move to SVN.
>
> For other examples, the GCC web page [1] lists such operating systems
> as
> Unicos/Mk, or LynxOS,
LynxOS is about to be removed (as in, in the next few days), unless i'm
misremembering (it's finals time for me, so it's possible).
I'm not sure Unicos still works.
> which I don't think APR has been ported to. Or
> Unos (which I couldn't even find in google). Or, to be really evil,
> people mention VMS occasionally on gcc lists.
> The port at least used to
> work (I think).
>
> Of course, the GCC project could decide that all of these platforms
> could use gcc, but without native development on them with revision
> control.
Errr, you honestly think that people work on gcc on <insert weird
platform> in a native environment?
The important list is the list of primary and secondary supported
platforms, which tell you which platforms gcc releases are required and
expected to work on (respectively, where expected means "tested but
non-showstopper bugs won't hold up the release") before it is released.
AFAIK, APR is already compilable on these.
> I don't know how they would feel about that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by sam th <sa...@uchicago.edu>.
On Mon, 2002-12-09 at 19:58, Ryan Bloom wrote:
> On Monday 09 December 2002 05:44 pm, sam th wrote:
> >
> > [2] It should be noted that SVN fails requirement 0. Hopefully the APR
> > people consider this an issue as well.
> APR is being used in Apache 2.0 currently, and currently works on: Every
> known version of Unix, Windows(all versions), Mac OS X, OS/2, BeOS, OS/390,
> and AS/400. What platforms are we missing?
For example, APR doesn't, to my knowledge, work on QNX. That's just off
the top of my head, since AbiWord does work on QNX, and we'd need a port
to move to SVN.
For other examples, the GCC web page [1] lists such operating systems as
Unicos/Mk, or LynxOS, which I don't think APR has been ported to. Or
Unos (which I couldn't even find in google). Or, to be really evil,
people mention VMS occasionally on gcc lists. The port at least used to
work (I think).
Of course, the GCC project could decide that all of these platforms
could use gcc, but without native development on them with revision
control. I don't know how they would feel about that.
[1] http://gcc.gnu.org/install/specific.html
--
sam th <sa...@uchicago.edu>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Ryan Bloom <rb...@covalent.net>.
On Monday 09 December 2002 05:44 pm, sam th wrote:
> In a discussion with Tom Lord on the GCC list, Zack Weinberg [1] posted
> an excellent list of requirements for a source control system. Some of
> them are for the future, some of them are requirements for anything that
> wants to replace CVS. They're worth taking a look at. [2]
>
> http://gcc.gnu.org/ml/gcc/2002-12/msg00444.html
>
> [1] Who I know is on this list, but hasn't mentioned his list on this
> list. Hope I'm not stepping on your toes, Zack.
>
> [2] It should be noted that SVN fails requirement 0. Hopefully the APR
> people consider this an issue as well.
I'm confused. As a beginner SVN person and the first APR developer, how does
SVN fail requirement 0 right now? If it is in reliability, there is nothing
that the APR developers can do. I don't believe that SVN isn't as portable
as CVS currently. APR has the goal of being insanely portable. The only
platform that I currently know of that doesn't have an APR port is Mac OS 9.
There are some platforms that may be improved by getting a native
implementation, such as AtheOS.
APR is being used in Apache 2.0 currently, and currently works on: Every
known version of Unix, Windows(all versions), Mac OS X, OS/2, BeOS, OS/390,
and AS/400. What platforms are we missing?
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Peter Davis <pe...@pdavis.cx>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 09 December 2002 20:20, Robert W Anderson wrote:
> Can I create "my own branch" in Subversion if I don't have write access
> to the repository? From what I've read it seems like the answer is no,
> but I'm trying to reconcile this with this "very easy" claim:
> Contacting someone by email and convincing them that I'm trustworthy
> enough to grant write access can be anything but easy.
That's a completely different subject: from what I understand, microbranches
are useful for resolving conflicts during a commit, which implies that you
already have commit access.
You are talking about remote repositories, where you create your own
repository down-stream from the "official" repository, and the two
repositories can merge change-sets back and forth between each other.
Subversion doesn't do this (BitKeeper does), but it might some day.
I do claim that creating branches in Subversion is "very easy", but I never
made any claims that you can create your own branch without write access.
That's an issue that has already been discussed on this list and will be
raised again in the future. CVS can't do it, and Subversion won't either for
the time being. For now, use "svn diff | mail".
- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE99XBHhDAgUT1yirARAg1rAJ94KFnU/OG2dgZ/PNZFtDQX5pFdvgCeMyXl
OjBjfBxa6W1DET/jSPsRWFM=
=dVEL
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Robert North <aq...@sneakemail.com>.
Peter Davis peter-at-pdavis.cx |Subversion list| wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Tuesday 10 December 2002 04:04, Robert North wrote:
>
>
>>>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?
>>>
>>>
>>My assumption would be that best practice says: work on the trunk, if
>>possible. So, normally you'd only have the contents of a single commit on
>>your branch, followed by an update fron the trunk, some conflict
>>resoloution, and a commit to the trunk.
>>
>>
>
>I still see a problem there. Doing the conflict resolution in the branch
>takes time, during which someone else could have made another commit to the
>trunk. Once that happens, the branch would be out of date, and when
>committing the merged changes from the branch to trunk, it'd have to create a
>new branch to resolve the new conflicts.
>
If there are further conficts, then it's just as much a pain, as if
there were no "microbranches".
Have a look at <http://gcc.gnu.org/ml/gcc/2002-12/msg00487.html>
(As suggested by Zack elsehere in this thead) which explains far better
that I can, how this idea may work and deals precisely with the issue
you raise about
multiple commits.
For my needs, most of the infrastucture is already available. It's just
a case of stringing together a bunch of svn commands.
For gcc, I think they would require a more shrinkwrapped system.
Cheers
-Rob.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Peter Davis <pe...@pdavis.cx>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 10 December 2002 04:04, Robert North wrote:
> > 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?
>
> My assumption would be that best practice says: work on the trunk, if
> possible. So, normally you'd only have the contents of a single commit on
> your branch, followed by an update fron the trunk, some conflict
> resoloution, and a commit to the trunk.
I still see a problem there. Doing the conflict resolution in the branch
takes time, during which someone else could have made another commit to the
trunk. Once that happens, the branch would be out of date, and when
committing the merged changes from the branch to trunk, it'd have to create a
new branch to resolve the new conflicts.
Maybe there's nothing technically impossible about that, but it would be
annoying. On the other hand, the chances of that happening would be rare
(even for a large project).
- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE99joihDAgUT1yirARAhlwAKCfB+IgqKUWhF+3KAFsjKdqSGt3bwCePiJr
lME8oL4e5aZ+ZMvrEp9xd3c=
=p1VA
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Peter Davis <pe...@pdavis.cx>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 09 December 2002 20:00, Martin Pool wrote:
> I've started using the micropattern of putting all submitted patches
> as diffs into a subdirectory of the CVS tree.
I have my own pattern of creating a directory for each open issue (bug) and
creating branches and storing patches within that directory. (I actually
track the issue descriptions and comments in this same directory, but that's
not the point.) For example:
/issue/
new/
i000100/ # Issue number 100
description
... # comments, patches, addendums
branch/
... # branches for working on the issue's fix
assigned/
pediddle/ # issues assigned to me (pediddle)
... # more issues
resolved/
... # more issues
So basically all work gets done in a branch, and the branch is stored along
side the issue description and any relevant patches.
Just in case anyone cared :-)
- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE99XLbhDAgUT1yirARAgPsAJwPjfZqC70f9QPHebvNOzRz6SrDvACbBfHk
jJ78P5vtEWnHvygsuxVOu1Y=
=5byX
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
"binding surfaces" (was: gcc source management requirements)
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Dec 14, 2002 at 03:04:52AM -0500, Jim Blandy wrote:
>...
> And generally structuring Subversion as a bunch of libraries was, at
> least in part, another attempt to increase its hackability: since
> there are a bunch of internal interfaces designed carefully enough
> that one can learn and use them, people have a lot more options for
> where to plug new and weird stuff in. If you understand Subversion's
> 'editors', you can go a long way.
A friend of mine referred to this as "having binding surfaces" (as in the
chemistry term). There are all kinds of ways that people can write stuff
that binds to SVN. He credits the Apache web server's success as due to its
large number of binding surfaces, and I tend to agree. The Apache web server
isn't the fastest, isn't the best-architected, but hoo boy... it can do just
about everything if you plug in the right modules. And *that* makes it
successful.
I see the same thing for Subversion, and it is also why I care so much about
the SWIG bindings. Not only can you use the libraries to do all kinds of
cool stuff, you can now do it with your favorite language. The tool/examples
directory has got a lot of stuff that demonstrates how to quickly get neato
functionality going with minimal investment.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
architectural and project plan improvements
Posted by Tom Lord <lo...@regexps.com>.
[Arch-dev list readers: this sketch suggests a clean architectural
approach to the "revision library drives repository" idea that is
sometimes kicked around. It arises out of some talk on svn's dev list
and is proposed there as a cleaner interface for svn-style storage
mgt.]
jimb:
> wrinkles increase the initial investment of mind needed to
> use the thing to the point where the project just isn't as
> exciting any more to the hacking public. They raise the
> hacktivation energy needed.
Yes, excessive intertwingling subverts good software and yadda yadda
yadda. So, that's the useful software mysticism.
Ok, let's give ourselves something more concrete than "hacktivation
energy" to talk about. In this message, I'll just sketch a revised
spec for the svn storage manager and how it relates to a revision
control client. It may seem a bit foreign or "far off the current
path" at first glance -- but I think closer examination will show that
this is a practical alternative path that leads (roughly speaking) to
a superset of your 1.0 target, superior in functionality,
simpler/cleaner in implementation -- it will _save_ you work in the
short-to-medium term.
Let's suppose I want to define an FSDB -- a "file system database".
FSDB is in the same general category as OODB or RDBMS, but it differs
from those other systems in terms of how storage is organized and
accessed.
An FSDB has (something close to) the following access methods:
GET <txn> <path> [<start> <length>]
PUT <txn> <path> [<start> <length>] <data>
Retrieve (store) the contents (or partial contents) of a
file.
RENAM <txn> <from-path> <to-path>
RNMDIR <txn> <from-path> <to-path>
Rename a file (directory).
COPY <txn> <from-path> <to-path>
Copy a file. This could in principle be synthesized from
GET and PUT, but this method does not require transfer of
data back and forth from storage manager to client.
CLNDIR <txn> <from-path> <to-path>
Clone a directory tree. Semantically, a `cp -r' operation.
LIST <txn> <dir-path> [<options>]
Retrieve a list of files in a directory.
REMOVE <txn> <dir-path>
RMDIR <txn> <dir-path>
RMDIRR <txn> <dir-path>
Remove a file (empty directory, non-empty directory).
My (unverified) understanding is that some of the BSD file systems and
some linux file systems and recent NFS RFCs have limited forms of file
properties. The following methods capture a least common denominator
of those systems:
GETPRP <txn> <dir-path> <prop>
PUTPRP <txn> <dir-path> <prop> <data>
Retrieve (store) a file property value. This _might_
subsume STAT functionality (retrieve file size, inode
number, etc. -- or maybe STAT is separate). Properties
are (most likely) simple length-limited strings -- 0
terminated for property names, binary for data.
Symbolic links and permissions:
SYMLNK <txn> <from-path> <to-path>
RDLINK <txn> <link-path>
Make (read) a symbolic link.
CHMOD <txn> <path> <mod-changes>
GETMOD <txn> <path>
Change (query) ugo file permissions. Some native file
systems now have access lists, and these methods might
be able to handle those as well.
And the tricky ones:
MKTXN <authdata> [r|w]
ENDTXN <txn>
KILTXN <txn>
Begin (end, kill) a transaction. All other methods may
only be invoked within a transaction.
Finally, let's add two operations that are critical to keeping network
traffic down:
DOPTCH <txn> <dir-path> <changeset>
MKPTCH <txn> <orig-dir-path> <mod-dir-path>
Apply (retrieve) a changeset in the format of RFC????.
I'm not going to speak, in this note, about how deadlocks are resolved
and so forth. Similarly, I'm not going to say anything about user
authentication.
Some things to note:
1) No (client visible) "repository version number".
2) Destructive operations (e.g. PUT, RMDIR).
3) No log messages.
4) Minimalist approaches to file properties and access lists.
5) COPY and CLNDIR provide hints to the server about when to
use delta-compressed storage. No (client visible)
history-independent file ids.
6) The changeset format is strictly orthogonal to everything
else. It applies equally well to native file systems, for
example.
7) Structure and access methods modeled after native file
systems. Indeed, this access protocol admits a very simple
implementation that uses native file systems, hard links,
and a few simple control files as a one possible
implementation (moderately efficient, probably not
making any use of delta-compressed storage, possibly making
use of compressed storage).
8) No leakage to server-side of the concept of a working
directory.
Did I leave anything out? A system roughly like that should
characterize the repository in a C api and CLI. Both APIs should be
"network transparent". I believe that this is CLOSE to what you have
-- a nice target that could be hit via slight refactorings, clean-ups,
simplifications, and some careful thinking about auth and txn
semantics. It's a target that you _could_ conceivably hit by layering
_over_ the existing svn client libraries -- but that would be putting
the cart before the horse by doing far more work overall than is
needed. The end result will be a far more useful storage manager, a
cleaner architecture overall, a simpler implementation, a more readily
explainable rev. ctl client, and yadda yadda yadda. (At least, IMO.)
Now, guess what: that's _all you need_ to build a strictly layered
(client side) revision control system (and many other handy apps,
besides). For example, where you currently need the repository
version number, you can instead use information embedded in paths to
cloned directories. For revision control, I'd hope that you would do
this in two parts:
1) A set of formally speced conventions that describe how
revision control data is mapped into the file system.
2) Clients, in various styles, that put a user interface
on those conventions.
Arch has demonstrated (and given good design hints) that distributed
revision control can be implemented client-side -- mostly by picking
good, global names. A server-side MKPTCH method complements the
arch-style design beautifully.
Finally, if you want to get really serious about taking on OODB and
RDBMS systems, you can add something along the lines of:
MKINDX <txn> <path> [<params>]
IXPUT <txn> <path> (<key> <value>)*
IXGET <txn> <path> <key>*
Manage special files (not accessible with GET or PUT) that
provide a low-level indexing facility. In good
implementations, cloning one of these special files implies
a space-efficient representation of the two resulting
indexes.
MKPGFL <txn> <path> [<params>]
PFGET <txn> <path> <page-id>
PFPUT <txn> <path> <page-id> <page-data>
Manage special files that are optimized for page-oriented
access.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Jim Blandy <ji...@red-bean.com>.
Tom Lord <lo...@regexps.com> writes:
> One of the (unstated?) goals in Subversion was to keep the
> server's semantics very simple, and push as much as possible
> into the clients.
>
> Very close to that idea, and, imo a better idea, is to not only keep
> the server semantics simple, but also to make a very simple client
> (both interactive and, in multiple ways, programmatic). Then strictly
> layer the "CVS replacement" UI (whatever that means) over that.
[I have the feeling that if it were not so late, I wouldn't have
written so much here. I hope it is coherent.]
I think you're getting at "hackability". I really hope Subversion is
hackable.
I usually get funny looks when I say that how easy something is to
explain --- and I mean, explain well enough that your listener can go
start using the thing --- should be a primary concern. Generally,
folks are happy to handle each problem by adding a new wrinkle,
introducing a new concept to the API, but over time, I believe those
wrinkles increase the initial investment of mind needed to use the
thing to the point where the project just isn't as exciting any more
to the hacking public. They raise the hacktivation energy needed.
You've really got to have a few simple concepts that get you almost
all the way there, because you can't afford more than that before you
start losing people.
This is one of the reasons I like Greg Hudson's protocol so much more
than DAV. When I read the DAV specs, my eyes glaze over faster than
donuts in a Krispy Kreme factory. No offense meant to the amazing
contributions Greg Stein has made to Subversion (I usually keep my
reservations about DAV to myself in appreciation of his efforts), but
he has just never seen DAV's complexity as much of a problem.
In contrast, I'll predict that, because anyone can look at a trace of
Greg Hudson's protocol and start writing their own thing that speaks
it just fine, anyone will, and you'll see a ton of interesting stuff
come out of that. (I guess the mindshare DAV holds will ensure
interesting stuff on that front, too. Subversion benefits either
way.)
The filesystem does have a well-defined interface and semantics all by
itself, in the absence of any network protocol, working copies,
etc. at all. This was to help people write other tools that work on
Subversion filesystems.
And generally structuring Subversion as a bunch of libraries was, at
least in part, another attempt to increase its hackability: since
there are a bunch of internal interfaces designed carefully enough
that one can learn and use them, people have a lot more options for
where to plug new and weird stuff in. If you understand Subversion's
'editors', you can go a long way.
Sure, some of those interfaces still have only one client, so they may
have gotten all wrinkly and incestuous. But the principle is
certainly there.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Tom Lord <lo...@regexps.com>.
One of the (unstated?) goals in Subversion was to keep the
server's semantics very simple, and push as much as possible
into the clients.
Very close to that idea, and, imo a better idea, is to not only keep
the server semantics simple, but also to make a very simple client
(both interactive and, in multiple ways, programmatic). Then strictly
layer the "CVS replacement" UI (whatever that means) over that.
That way you can develop a nice, clean semantics for "versioned file
system with cheap tree cloning", and then develop a source mgt tool
over that without succumbing to the temptation to pollute the file
system semantics in the name of expediency.
I suspect, not being totally familiar with your current code but
having read discussions here and at least some of your code/design
docs, that you already do have some layering along these lines -- but
it seems to me that:
(a) A CLI for "just the filesystem" is highly desirable.
(b) A spec document of the semantics of "just the filesystem"
is highly desirable.
(c) In recent design discussions, you tend to violate this
layering, as for example when you consider solving source
mgt problems by changing the semantics of file properties.
To further clarify: a nice CLI for "versioned file system...", would,
I suspect, have no such concept as a working directory. Working
directories would come in the layer above.
When I say that a filesystem spec and CLI is "highly desirable", I
mean at least two things: (1) it will likely have other applications;
(2) that layering discipline will improve your "cvs replacement"
design by giving it a more solid, less arbitrary foundation.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Jim Blandy <ji...@red-bean.com>.
Peter Davis <pe...@pdavis.cx> writes:
> 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 thing to keep in mind is that whether one creates microbranches or
not, etc. is sort of a client issue. The server can store them
efficiently; the protocol lets you create them efficiently; what
features you provide with those facilities is up to the client.
One of the (unstated?) goals in Subversion was to keep the server's
semantics very simple, and push as much as possible into the clients.
It's much easier to experiment with new features on the client side:
- client-side bugs alone can't compromise the history on the server,
since there are no protocol requests that modify history (that's
still true, right?), and
- unlike the server, clients don't have to be shared by all the
developers on a project: one person can try out his own stuff
without inconveniencing everyone else.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Ben Collins-Sussman <su...@collab.net>.
Robert North <aq...@sneakemail.com> writes:
> 2. Branching At present, I don't think you can make a branch and
> commit to it, if your sandbox is on the trunk and the sandbox
> contains modifications.
Sneaky trick:
Suppose I have a working copy of /trunk, with local mods.
$ svn switch http://host/branches/some-branch
# (wc is updated to reflect new location, mods are preserved.)
$ svn commit
$ svn switch http://host/trunk
:-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Robert North <aq...@sneakemail.com>.
Peter Davis peter-at-pdavis.cx |Subversion list| wrote:
>-----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.
>
2 Points here,
1. The Commit/Update process.
I think a commit should still fail if there's outstanding updates.
You then have a choice
a. commit to a branch and continue working, (probably imediately
doing an update on the trunk)
b. update from trunk, then comit.
2. Branching
At present, I don't think you can make a branch and commit to it, if
your sandbox is on
the trunk and the sandbox contains modifications.
I haven't tested that though.
>
>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?
>
My assumption would be that best practice says: work on the trunk, if
possible.
So, normally you'd only have the contents of a single commit on your
branch, followed by an update fron the trunk,
some conflict resoloution, and a commit to the trunk.
I think what you're moving towards is something like a vendor-trunk
relationship here (something I don't fully understand)
>
>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).
>
So long as subversion provides the infrastucture, users can script to
create their desired
behaviour.
Apologies to Peter, for sending a mangled version of this mail to his inbox.
-Rob.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2002-12-13 at 22:03, Branko Čibej wrote:
> >basically a failed commit is an unfinished transaction, which violates
> >repository policy (e.g. not the branch's head was used as the base).
> >Now instead of forcing a transaction rollback now, if we allow the
> >client to keep the transaction open and do further work on it, we
> >suddenly do have "microbranches" for free.
> Oooh, someone else has thought of long-lived transactions. Welcome to
> the club. :-)
A note here:
With the current FS code, we could treat unfinished transactions as
microbranches. But if a transaction fails to automerge, no amount of
additional work on the transaction will make it commitable. You can't
currently change a transaction so that "this file here, which used to
have base revision 4, now has base revision 5, and these new contents."
(I have 90% certainty in the previous statements.)
Even with that limitation, you could:
* Leave the transaction around in the repository forever, so that the
data doesn't get lost.
* Merge the transaction's changes against a more current WC, producing
something commitable.
But that's actually not a bad discipline. If you do the merge *from*
the unfinished transaction instead of *to* it, then you never destroy
the information about what you previously wanted to commit.
Of course, these things would require noticeable changes to the layers
on top of the FS (libsvn_ra, libsvn_client, and the command-line client
itself).
Other things you can do with long-lived transactions (nothing people
haven't mentioned on this list before):
* Escrow potential commits for code review.
* Implement a client interface for wc-less manipulations of the
repository. Such an interface could allow a series of O(1) tree
manipulations to take place within a single transaction, without the
potentially large expense of representing the new state in a working
copy.
The one thing we don't want to do is implement intermediate commits
within long-lived transactions. That would cross the line from
"microbranches" to "real branches," and we already have a different way
of doing branches. (Plus, it would involve changing the filesystem
schema, whereas none of the previously mentioned functionality requires
any changes to the FS.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Branko Čibej <br...@xbc.nu>.
Philipp wrote:
>On Mon, 09 Dez 2002, Peter Davis wrote:
>
>
>
>>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.
>>
>>
>
>looking from the DAV point of view, i just found another alternative
>interpretation, which should be roughly compatible with standard
>subversion commit semantics:
>
>basically a failed commit is an unfinished transaction, which violates
>repository policy (e.g. not the branch's head was used as the base).
>Now instead of forcing a transaction rollback now, if we allow the
>client to keep the transaction open and do further work on it, we
>suddenly do have "microbranches" for free. (User can e.g. apply
>HEAD-2:HEAD, with manual merging where necessary, and then try the
>commit again.)
>
>Can anybody see where i'm trying to get at and if this would be useful ?
>
Oooh, someone else has thought of long-lived transactions. Welcome to
the club. :-)
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Philipp <pi...@users.sourceforge.org>.
On Mon, 09 Dez 2002, Peter Davis wrote:
>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.
looking from the DAV point of view, i just found another alternative
interpretation, which should be roughly compatible with standard
subversion commit semantics:
basically a failed commit is an unfinished transaction, which violates
repository policy (e.g. not the branch's head was used as the base).
Now instead of forcing a transaction rollback now, if we allow the
client to keep the transaction open and do further work on it, we
suddenly do have "microbranches" for free. (User can e.g. apply
HEAD-2:HEAD, with manual merging where necessary, and then try the
commit again.)
Can anybody see where i'm trying to get at and if this would be useful ?
Bye,
Philipp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Robert W Anderson <rw...@alumni.princeton.edu>.
Peter Davis wrote:
>-----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,
>
Can I create "my own branch" in Subversion if I don't have write access
to the repository? From what I've read it seems like the answer is no,
but I'm trying to reconcile this with this "very easy" claim:
Contacting someone by email and convincing them that I'm trustworthy
enough to grant write access can be anything but easy.
Thanks,
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Martin Pool <mb...@sourcefrog.net>.
> >> 4) GCC, more than many projects, makes use of a formal review
> >> process for incoming patches.
> > Yes.
> This is a strength, but with a downside -- patches can and do get
> lost. We advise people to re-send patches at intervals, but some
> sort of automated patch-tracker would probably be helpful. I don't
> think the version control system can help much here (but see below).
I've started using the micropattern of putting all submitted patches
as diffs into a subdirectory of the CVS tree. As a small example:
http://cvs.samba.org/cvsweb/distcc/patches/
This has a few benefits:
- they're easier to find there than in a mail archive or somebody's
hard disk
- if an updated version is submitted it can be updated in CVS and
tracked, so people can easily find the most recent revision
- they can be deleted (and therefore "marked closed") when they're
either merged into the main tree or obsolete
- patches that are not generalized but perhaps useful on a particular
platform or situation can be found and applied by people who need
it
- it's more motivating to people sending patches that it is at least
"half accepted" rather than apparently ignored
- you can add comments about the patch in commit messages or at the
start of the patch
- it's easier than setting up a separate patch tracking tool, and just
saving from a mail reader straight into a patches/ directory is quicker
than going through a web interface
I don't know if this would work for the (obviously much larger) gcc
project, but I find it useful.
--
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Peter Davis <pe...@pdavis.cx>.
-----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
Re: gcc source management requirements
Posted by Robert North <aq...@sneakemail.com>.
>
>
>
>(2f): I'm not quite sure what this is asking, but AFAIK Subversion doesn't
>create "microbranches" to resolve conflicts. Conflicts are resolved in the
>working copy, but remember that copies of all three versions of a merged file
>are available. How would "microbranches" be used and why are they necessary?
>
>
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.
As for the true definition of microbranches, a Google search turned up
nothing.
-Rob.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Branko Čibej <br...@xbc.nu>.
Peter Davis wrote:
>(2f): I'm not quite sure what this is asking, but AFAIK Subversion doesn't
>create "microbranches" to resolve conflicts. Conflicts are resolved in the
>working copy, but remember that copies of all three versions of a merged file
>are available. How would "microbranches" be used and why are they necessary?
>
It's the way a real changeset engine (which Subversion isn't) works.
BitKeeper is an example, Arch probably is, too.
>(5): Automatic ChangeLog updates are in the domain of a new post-commit
>script. Sounds like an interesting idea, but supporting GCC's or any other
>project's specific changelog format -- not to mention enforcing humans to use
>a machine-parseable log message format -- is something that should be handled
>elsewhere.
>
No, "svn log" _is_ an automatic ChangeLog generator, as long as the
commit log format is maintained. There's not only no need to maintain
ChangeLog files in the repository, it's much better _not_ to have them,
as they only complicate merging.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Zack Weinberg <za...@codesourcery.com> writes:
> I'm not sure Subversion does all the checksumming I'd like, yet.
Oh, you're not alone:
http://subversion.tigris.org/issues/show_bug.cgi?id=689
:-)
> > Sounds like an interesting idea, but supporting GCC's or any other
> > project's specific changelog format -- not to mention enforcing
> > humans to use a machine-parseable log message format -- is something
> > that should be handled elsewhere.
>
> Granted. Please read that as a request for the appropriate hooks, and
> (since that change log format is common to GNU projects and has spread
> beyond there) perhaps a place could be found for a user-contributed
> script that does this, in a "sample hook scripts" bundle distributed
> with Subversion.
The appropriate hooks already exist -- you could implement this now,
if you wanted, without changing Subversion code.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Robert North <aq...@sneakemail.com>.
Zack Weinberg zack-at-codesourcery.com |Subversion list| wrote:
>Branko Čibej <br...@xbc.nu> writes:
>
>
>>Zack Weinberg wrote:
>>
>>
>>>Peter Davis <pe...@pdavis.cx> writes:
>>>
>>>
>>>>(2d): Subversion currently doesn't do "smart merging", but neither
>>>>does CVS, and it will in the future.
>>>>
>>>>
>>>I may try to implement this myself, sometime early next year, if no
>>>one beats me to it. Shouldn't be hard.
>>>
>>>
>>Er, Zack? I suggest you think twice before saying "shouldn't be hard"
>>regarding something most of us have carefully avoided, for sanity's
>>sake. :-)
>>
>>Seriously: This is something that's fairly easy to hack up, but
>>excruciatingly difficult to get right.
>>
>>
>
>I'm aware of the difficulties and I have no intention of doing
>anything half-assed. However, I think that the feature can be phased
>in. In 1.0 I would really like to see Subversion record merge
>parents, even if it doesn't do anything with the information yet,
>because it's useful to humans and to future versions of the software.
>This is easy, if properties are used carry the information, which I
>think is reasonable.
>
>The second stage is 'smart merge' to the extent that ClearCase
>implements it: handling only intra-file changes and only when the
>entire content of a branch up to some point has been merged to another
>branch. It seems to me that this should also be easy, because the
>effect is simply to change the greatest common ancestor of the files
>involved in the merge. Just having this is enough for the feature to
>be broadly useful. I'd like to squeeze this into 1.0 but I wouldn't
>mind if it got delayed till 1.1.
>
Yes, I think this is doable in a short space of time.
But, I think it will probably rely on competely different infrastucture
from a 100% safe soloution.
Maybe it's best done in a script.
I was certainly considering a quick hack of this type for my personal use.
<Snip stages 3 & 4>
I think that the sbversioun guys may want handle the full problem by
representing version ancestry with some kind of directed acyclic graph
stucture, with rules to merge, and delete form the graph, plus of course
rules to compute the diffs to appy.
While I'm probably wrong about the method people are thinking of using
for a full implementation, I want
to demonstrate that it's unlikely to mesh well with a restricted
implementation.
-Rob.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Tom Lord <lo...@regexps.com>.
> If I'm missing something, please tell me.
You are.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Zack Weinberg <za...@codesourcery.com>.
Branko Čibej <br...@xbc.nu> writes:
> Zack Weinberg wrote:
>>Peter Davis <pe...@pdavis.cx> writes:
>>>(2d): Subversion currently doesn't do "smart merging", but neither
>>>does CVS, and it will in the future.
>>
>>I may try to implement this myself, sometime early next year, if no
>>one beats me to it. Shouldn't be hard.
>
> Er, Zack? I suggest you think twice before saying "shouldn't be hard"
> regarding something most of us have carefully avoided, for sanity's
> sake. :-)
>
> Seriously: This is something that's fairly easy to hack up, but
> excruciatingly difficult to get right.
I'm aware of the difficulties and I have no intention of doing
anything half-assed. However, I think that the feature can be phased
in. In 1.0 I would really like to see Subversion record merge
parents, even if it doesn't do anything with the information yet,
because it's useful to humans and to future versions of the software.
This is easy, if properties are used carry the information, which I
think is reasonable.
The second stage is 'smart merge' to the extent that ClearCase
implements it: handling only intra-file changes and only when the
entire content of a branch up to some point has been merged to another
branch. It seems to me that this should also be easy, because the
effect is simply to change the greatest common ancestor of the files
involved in the merge. Just having this is enough for the feature to
be broadly useful. I'd like to squeeze this into 1.0 but I wouldn't
mind if it got delayed till 1.1.
The third stage is handling extra-file changes -- tree rearrangements
and so on. This may fall nicely out of the way the SVN filesystem
works, or it may not; I'm not sure.
The fourth stage is what you're probably thinking of as
'excruciatingly difficult to get right': handling merges intelligently
in the presence of single deltas that have been added to or removed
from a branch. I agree that's hard, but I don't think it's necessary
for the first cut of the feature.
If I'm missing something, please tell me.
zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Tom Lord <lo...@regexps.com>.
Seriously: This [smart merging] is something that's [....]
excruciatingly difficult to get right.
I agree. (Ellision to make it clear what part I was agreeing with.)
It's orthogonal, though, to the core bit of functionality that svn
almost uniquely provides (selected files whole-tree transaction
orientation).
That's why I once suggested:
A) Reconsidering your 1.0 path: focus on a simplified
interface to storage mgt.
B) Consider helping to figure out how to use svn as an arch
back-end. In other words -- arch can be layered so that
its good merging support and changeset mgt. support is
orthogonal to storage mgt.
(A) falls under the general software tools admonishment to build tools
that "do one thing well".
(B) is the payoff for (A).
But it's a lot of work, of course.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Branko Čibej <br...@xbc.nu>.
Zack Weinberg wrote:
>Peter Davis <pe...@pdavis.cx> writes:
>
>>(2d): Subversion currently doesn't do "smart merging", but neither
>>does CVS, and it will in the future.
>>
>>
>
>I may try to implement this myself, sometime early next year, if no
>one beats me to it. Shouldn't be hard.
>
Er, Zack? I suggest you think twice before saying "shouldn't be hard"
regarding something most of us have carefully avoided, for sanity's
sake. :-)
Seriously: This is something that's fairly easy to hack up, but
excruciatingly difficult to get right.
>>(2f): I'm not quite sure what this is asking, but AFAIK Subversion
>>doesn't create "microbranches" to resolve conflicts. Conflicts are
>>resolved in the working copy, but remember that copies of all three
>>versions of a merged file are available. How would "microbranches"
>>be used and why are they necessary?
>>
>>
>
>See <http://gcc.gnu.org/ml/gcc/2002-12/msg00487.html> for a lengthy
>explanation.
>
>
>
>>(5): Automatic ChangeLog updates are in the domain of a new
>>post-commit script.
>>
>>
>
>Personally I would prefer a post-checkout/update script, so that the
>file doesn't even exist in the repository, but that's just me.
>
As I said elsewhere, "svn log" gives you exactly what you want, modulo
formatting issues, which can be dealt with.
>>Sounds like an interesting idea, but supporting GCC's or any other
>>project's specific changelog format -- not to mention enforcing
>>humans to use a machine-parseable log message format -- is something
>>that should be handled elsewhere.
>>
>>
>
>Granted. Please read that as a request for the appropriate hooks, and
>(since that change log format is common to GNU projects and has spread
>beyond there) perhaps a place could be found for a user-contributed
>script that does this, in a "sample hook scripts" bundle distributed
>with Subversion.
>
The good news is that Subversion can spit the changelogs out in XML
format, and converting those to anything else should be a piece of cake.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Peter Davis <pe...@pdavis.cx>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
With Subversion, it's even easier than that:
$ svn cp -r 754 http://.../trunk http://.../branches/helen/
$ svn switch http://.../branches/helen/ .
$ svn commit -m "..."
The switch command will replace the checkout and copy of the working copy for
the branch, and it will also preserve local mods. The commit will be made to
the branch.
Technically, the switch command merges the branch into the current directory,
so if someone had committed their own changes to the branch, those would be
merged as well (although that couldn't really happen in this use-case).
On Tuesday 10 December 2002 05:10, Ketil Z. Malde wrote:
> svn cp -r754 http://.../trunk http://.../branches/helen/
> svn co http://...branches/helen/ my_branch
> cp -a trunk/ my_branch/
> cd my_branch/
> svn commit -m ".."
- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE99jskhDAgUT1yirARAqf+AJwNKjsQYbTPndctuKx8brzTej3RogCdG739
PYWB1sTtgc6pkjh/sKlh0rE=
=TPpu
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by "Ketil Z. Malde" <ke...@ii.uib.no>.
Zack Weinberg <za...@codesourcery.com> writes:
>> (2f): I'm not quite sure what this is asking, but AFAIK Subversion
>> doesn't create "microbranches" to resolve conflicts.
> See <http://gcc.gnu.org/ml/gcc/2002-12/msg00487.html> for a lengthy
> explanation.
So Mel commits revision 754, which is checked out by Dave and Helen.
Dave commits 755, and Helen's update causes conflicts.
If I understand correctly, you would automate the process where Helen
manually make a branch at revision 754 and commit to that branch?
Something like (modulo bad syntax):
svn cp -r754 http://.../trunk http://.../branches/helen/
svn co http://...branches/helen/ my_branch
cp -a trunk/ my_branch/
cd my_branch/
svn commit -m ".."
Is it really important that it is automated? Does other tools support
this, and does it really solve your problem?
Of course, one problem is that Helen will probably try to do an
svn update
first, which will end in a bunch of conflicts. Is there any way in
SVN to undo such an update? Alternatively, is there a way to dry-run
an update to check for conflicts?
Anyway, it seems to me you might have the problem (in the example case
on the web page) without any actual conflicts in the update, so
perhaps that's the wrong track. Helen should probably use an explicit
branch, which is merged into the trunk.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Zack Weinberg <za...@codesourcery.com>.
Peter Davis <pe...@pdavis.cx> writes:
> On Monday 09 December 2002 17:44, sam th wrote:
>> It should be noted that SVN fails requirement 0.
>
> Some observations about the specific failures of the requirements:
>
> (0): Well, it only partially fails requirement 0. I guess it's up
> to the GCC people as to whether this is a "hard" requirement. I
> can't imagine that this should be such a big issue as long as the
> major and most of the minor architectures are covered. For the
> record, which architectures does CVS support that APR does not?
We're not totally inflexible on any of them, and I'm not aware of any
platforms CVS supports that APR does not.
I'm not sure Subversion does all the checksumming I'd like, yet.
> (0b): Berkeley-DB requires write access in order to create lock
> files, and AFAIK there is no way to fix this without using some
> other database. Would an audit of mod_dav_svn (or ra_svn) be a good
> alternative for this requirement?
An audit would be good in any case. This would be no worse than the
present situation with CVS, anyway. (I tend to go into maximally
paranoid mode when talking about security requirements.)
> (1): While Subversion passes all of (1a) through (1d), the every day
> operations (checkout, status) are in fact slower, but not usually by
> a great amount, and not in any way that can't be optimized in the
> future. The truly braindead things about CVS, including network
> transfers, branching, and tagging, have all been fixed as a feature
> of the basic design.
I'm concerned about the graphs that someone posted a couple weeks
back, showing Subversion scale linearly but with a much larger
constant than CVS. GCC's repository is quite large - 884MB, 19723 ,v
files; when one of the major complaints about CVS is "it's too slow,"
switching to a slower system - even if that's something that can
easily be fixed in the future - is not in the cards.
> (2d): Subversion currently doesn't do "smart merging", but neither
> does CVS, and it will in the future.
I may try to implement this myself, sometime early next year, if no
one beats me to it. Shouldn't be hard.
> (2f): I'm not quite sure what this is asking, but AFAIK Subversion
> doesn't create "microbranches" to resolve conflicts. Conflicts are
> resolved in the working copy, but remember that copies of all three
> versions of a merged file are available. How would "microbranches"
> be used and why are they necessary?
See <http://gcc.gnu.org/ml/gcc/2002-12/msg00487.html> for a lengthy
explanation.
> (5): Automatic ChangeLog updates are in the domain of a new
> post-commit script.
Personally I would prefer a post-checkout/update script, so that the
file doesn't even exist in the repository, but that's just me.
> Sounds like an interesting idea, but supporting GCC's or any other
> project's specific changelog format -- not to mention enforcing
> humans to use a machine-parseable log message format -- is something
> that should be handled elsewhere.
Granted. Please read that as a request for the appropriate hooks, and
(since that change log format is common to GNU projects and has spread
beyond there) perhaps a place could be found for a user-contributed
script that does this, in a "sample hook scripts" bundle distributed
with Subversion.
zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Peter Davis <pe...@pdavis.cx>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 09 December 2002 17:44, sam th wrote:
> It should be noted that SVN fails requirement 0.
Some observations about the specific failures of the requirements:
(0): Well, it only partially fails requirement 0. I guess it's up to the GCC
people as to whether this is a "hard" requirement. I can't imagine that this
should be such a big issue as long as the major and most of the minor
architectures are covered. For the record, which architectures does CVS
support that APR does not?
(0b): Berkeley-DB requires write access in order to create lock files, and
AFAIK there is no way to fix this without using some other database. Would
an audit of mod_dav_svn (or ra_svn) be a good alternative for this
requirement?
(1): While Subversion passes all of (1a) through (1d), the every day
operations (checkout, status) are in fact slower, but not usually by a great
amount, and not in any way that can't be optimized in the future. The truly
braindead things about CVS, including network transfers, branching, and
tagging, have all been fixed as a feature of the basic design.
(2d): Subversion currently doesn't do "smart merging", but neither does CVS,
and it will in the future.
(2f): I'm not quite sure what this is asking, but AFAIK Subversion doesn't
create "microbranches" to resolve conflicts. Conflicts are resolved in the
working copy, but remember that copies of all three versions of a merged file
are available. How would "microbranches" be used and why are they necessary?
(5): Automatic ChangeLog updates are in the domain of a new post-commit
script. Sounds like an interesting idea, but supporting GCC's or any other
project's specific changelog format -- not to mention enforcing humans to use
a machine-parseable log message format -- is something that should be handled
elsewhere.
- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE99U/bhDAgUT1yirARAgAXAJ9EKjbdjoWdzNw0fI7NuatLShHotwCdGSyt
GrB31Y7PJitVImAhlS9SWxI=
=DpAm
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Nuutti Kotivuori <na...@iki.fi>.
Branko wrote:
> Of course we fail on the portability part. We havent even tested SVN
> on many major platforms in ages. The only systems that IIRC get
> regular testing are:
>
> Linux, ia32 flavours
> FreeBSD, also ia32
> Windows 2000/XP
> Mac OS X
> Solaris 7
> HP-UX (client-only, server doesn't work)
>
> Of the major platforms, we're missing at least AIX and the non-ia32
> flavours of Linux. We don't even support two ports that APR
> explicitly does -- Netware and OS/2.
Subversion is nowadays in Debian - which means that it will get
regular testing on Linux with several non-ia32 flavours. David Kimdon
appears to be running the test suite upon every build on those
platforms. In addition, I think Ben Collins is running Subversion on
IA-64 and updating pretty often.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by David Kimdon <dw...@debian.org>.
On Wed, Dec 11, 2002 at 02:15:22AM +0000, Philip Martin wrote:
> Branko ??ibej <br...@xbc.nu> writes:
>
> > Of the major platforms, we're missing at least AIX and the non-ia32
> > flavours of Linux.
>
> http://buildd.debian.org/build.php?arch=&pkg=subversion
>
> Ten non-ia32 Linux architectures, with mixed results...
>
> Now, if the Debian package was modified to "cat tests.log" if there is
> a test suite failure, it would be even better.
Good thinking, I'll do that for 0.16.0 (which I hope to upload soon,
just been busy. . .)
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Äibej <br...@xbc.nu> writes:
> Of the major platforms, we're missing at least AIX and the non-ia32
> flavours of Linux.
http://buildd.debian.org/build.php?arch=&pkg=subversion
Ten non-ia32 Linux architectures, with mixed results...
Now, if the Debian package was modified to "cat tests.log" if there is
a test suite failure, it would be even better.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Branko Čibej <br...@xbc.nu>.
Garrett Rooney wrote:
> Branko Čibej wrote:
>
>>> everything else (i think) we pass (or intend to pass by the time we
>>> hit 1.0), modulo the occasional bug of course.
>>>
>>
>>
>> The repeated-merge problem certainly isn't targetted for 1.0 at the
>> moment.
>>
>>
>
> the repeated merge problem was part of number 2, i said that we had
> not targeted that for 1.0.
Ah, sorry, I missed that.
>
>
> -garrett
>
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Branko Čibej wrote:
>>everything else (i think) we pass (or intend to pass by the time we
>>hit 1.0), modulo the occasional bug of course.
>>
>>
>
>The repeated-merge problem certainly isn't targetted for 1.0 at the moment.
>
>
the repeated merge problem was part of number 2, i said that we had not
targeted that for 1.0.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Nicholas Riley <nj...@uiuc.edu>.
On Tue, Dec 10, 2002 at 08:00:46PM -0800, Blair Zajac wrote:
> Branko ?ibej wrote:
> >
> > Of course we fail on the portability part. We havent even tested SVN on
> > many major platforms in ages. The only systems that IIRC get regular
> > testing are:
> >
> > Linux, ia32 flavours
> > FreeBSD, also ia32
> > Windows 2000/XP
> > Mac OS X
> > Solaris 7
> > HP-UX (client-only, server doesn't work)
>
> I test pretty regularly on IRIX and Solaris 8.
I test on PowerPC Linux (client only, so far) and IRIX as well, and
I'm sure at least one person tests on NetBSD. :-)
--
=Nicholas Riley <nj...@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
Pablo Research Group, Department of Computer Science and
Medical Scholars Program, University of Illinois at Urbana-Champaign
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Blair Zajac <bl...@orcaware.com>.
Branko ?ibej wrote:
>
> Of course we fail on the portability part. We havent even tested SVN on
> many major platforms in ages. The only systems that IIRC get regular
> testing are:
>
> Linux, ia32 flavours
> FreeBSD, also ia32
> Windows 2000/XP
> Mac OS X
> Solaris 7
> HP-UX (client-only, server doesn't work)
I test pretty regularly on IRIX and Solaris 8.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Branko Čibej <br...@xbc.nu>.
Garrett Rooney wrote:
> On Monday, December 9, 2002, at 08:44 PM, sam th wrote:
>
>> In a discussion with Tom Lord on the GCC list, Zack Weinberg [1] posted
>> an excellent list of requirements for a source control system. Some of
>> them are for the future, some of them are requirements for anything that
>> wants to replace CVS. They're worth taking a look at. [2]
>>
>> http://gcc.gnu.org/ml/gcc/2002-12/msg00444.html
>>
>> [1] Who I know is on this list, but hasn't mentioned his list on this
>> list. Hope I'm not stepping on your toes, Zack.
>>
>> [2] It should be noted that SVN fails requirement 0. Hopefully the APR
>> people consider this an issue as well.
>>
>
> well, which part of requirement 0 are you talking about? i don't
> believe we fail the portability part, at least for a client build
> (although for some of the more obscure platforms it remains to be proven).
Of course we fail on the portability part. We havent even tested SVN on
many major platforms in ages. The only systems that IIRC get regular
testing are:
Linux, ia32 flavours
FreeBSD, also ia32
Windows 2000/XP
Mac OS X
Solaris 7
HP-UX (client-only, server doesn't work)
Of the major platforms, we're missing at least AIX and the non-ia32
flavours of Linux. We don't even support two ports that APR explicitly
does -- Netware and OS/2.
> everything else (i think) we pass (or intend to pass by the time we
> hit 1.0), modulo the occasional bug of course.
The repeated-merge problem certainly isn't targetted for 1.0 at the moment.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gcc source management requirements
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Monday, December 9, 2002, at 08:44 PM, sam th wrote:
> In a discussion with Tom Lord on the GCC list, Zack Weinberg [1] posted
> an excellent list of requirements for a source control system. Some of
> them are for the future, some of them are requirements for anything
> that
> wants to replace CVS. They're worth taking a look at. [2]
>
> http://gcc.gnu.org/ml/gcc/2002-12/msg00444.html
>
> [1] Who I know is on this list, but hasn't mentioned his list on this
> list. Hope I'm not stepping on your toes, Zack.
>
> [2] It should be noted that SVN fails requirement 0. Hopefully the APR
> people consider this an issue as well.
>
well, which part of requirement 0 are you talking about? i don't
believe we fail the portability part, at least for a client build
(although for some of the more obscure platforms it remains to be
proven).
we definately fail the "anonymous access doesn't need a userid that can
write to the repos" test, since you need write access to open the
berkeley db files that make up the filesystem, so apache (and
mod_dav_svn) must be running as the user who owns the repos.
certainly we also fail the reliability portion, but that's largely
because the system hasn't had time to mature. as more people use it,
more and more bugs get shaken out of it. given time, i have no doubt
we will hit that requirement as well.
we also fail parts of 2, but that's just because we've chosen not to
deal with them until after 1.0.
everything else (i think) we pass (or intend to pass by the time we hit
1.0), modulo the occasional bug of course.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org