You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Nicklas Larsson <ki...@lysator.liu.se> on 2002/05/01 17:24:02 UTC
Features and release dates
Hi,
I just saw that the feature list for version 1.0 has been changed on the
project page.
I have been hoping for some time now that the company that I work for will
switch over to SubVersion in the not to distant future. We currently use
CVS.
Now, when I read that 1.0 will probably not include annotate and module
support, the most obvious question is, how much longer will it take to
finish the version with annotate and module support?
Another thing that I would like to ask is if something important in the
database will change between 1.0 and x.x when modules are supported? Is it
safe for a company to start using SubVersion at version 1.0?
In SubVersion 1.0, will it be possible to emulate CVS modules?
Will SubVersion 1.0 be able to convert a CVS repository on its release
date?
// Nicklas Larsson
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how to tell what I need to 'svn add' ?
Posted by Alexis Huxley <ah...@gmx.net>.
> > rm some-other-existing-file.c
> > svn del some-other-existing-file.c
>
> you can skip the rm. assuming you haven't made any changes to the
> file, svn rm will get rid of it for you.
Yes, but I can imagine a scenario where you *thought*
some-other-existing-file.c was not needed any more but actually it was,
which not removing it immediately will not reveal to you. i.e. 'make'
doesn't know you've typed 'svn del' ;-)
> > make
> > make clean <-- so I don't check in objects, etc
>
> no need for this step. 'svn commit' will only commit things you have
> explicitly added. the object files won't get checked in unless you
> specifically tell it to.
Yes, in this case that's now clear to me.
Ok, I'll go and play for a bit more now, thanks all.
Alexis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how to tell what I need to 'svn add' ?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, May 01, 2002 at 09:13:06PM +0200, Alexis Huxley wrote:
> So, the correct cycle for a mod/add/del from scratch is:
>
> svn co <uri-for-whatever>
> cd <whatever>
> vi some-new-file.c
> vi some-other-new-file.c
> svn st
> svn add some-new-file.c <-- add what is unknown to working copy
> svn add some-other-new-file.c
> vi some-existing-file.c
> rm some-other-existing-file.c
> svn del some-other-existing-file.c
you can skip the rm. assuming you haven't made any changes to the
file, svn rm will get rid of it for you.
> make
> make clean <-- so I don't check in objects, etc
no need for this step. 'svn commit' will only commit things you have
explicitly added. the object files won't get checked in unless you
specifically tell it to.
> cd -
> svn commit
>
> Is that right? Thanks for all the help ...
other than those two things, yep.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how to tell what I need to 'svn add' ?
Posted by Ben Collins-Sussman <su...@collab.net>.
Alexis Huxley <ah...@gmx.net> writes:
> svn co <uri-for-whatever>
> cd <whatever>
> vi some-new-file.c
> vi some-other-new-file.c
> svn st
> svn add some-new-file.c <-- add what is unknown to working copy
> svn add some-other-new-file.c
> vi some-existing-file.c
> rm some-other-existing-file.c
> svn del some-other-existing-file.c
> make
> make clean <-- so I don't check in objects, etc
> cd -
> svn commit
Sure, that works. A couple of points:
* you don't need to worry about committing object files. did you
explicitly schedule them for addition using 'svn add'? If not,
they won't be committed. They're just ignored, unversioned files.
* most people tend to run 'svn update' before committing, to make
sure they don't receive any conflicting changes from other people.
They also tend to run 'svn status' to make sure they're committing
the list of changes they want. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how to tell what I need to 'svn add' ?
Posted by Alexis Huxley <ah...@gmx.net>.
Nathan wrote:
> When you invoke 'svn st' it will show all the files that the client does
> not know about, preceeded with a question mark, except those being
> ignored, of course.
Ah ... super thanks!
Ben wrote:
> That's true. 'svn diff' shows local modifications to your working
> copy. A scheduled addition is a type of local modification. That's
> why it's probably easier to just 'svn add' files right when you create
> them -- you'll see them in the diffs. You can always un-schedule the
> addition later if you want.
So, the correct cycle for a mod/add/del from scratch is:
svn co <uri-for-whatever>
cd <whatever>
vi some-new-file.c
vi some-other-new-file.c
svn st
svn add some-new-file.c <-- add what is unknown to working copy
svn add some-other-new-file.c
vi some-existing-file.c
rm some-other-existing-file.c
svn del some-other-existing-file.c
make
make clean <-- so I don't check in objects, etc
cd -
svn commit
Is that right? Thanks for all the help ...
Studiously,
Alexis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how to tell what I need to 'svn add' ?
Posted by Nathan Fiedler <nf...@bluemarsh.com>.
When you invoke 'svn st' it will show all the files that the client does
not know about, preceeded with a question mark, except those being
ignored, of course.
nathan
On Wed, 2002-05-01 at 11:43, Alexis Huxley wrote:
> Does such a oh-yes-thanks-for-reminding-me-that-i-created-that-file-
> but-haven't-svn-added-it-yet tool exist, or do I have to change
> the way I work? Can anyone offer technical or philosophical advice,
> or point me in the direction of something explaining these things?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how to tell what I need to 'svn add' ?
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> Therefore, it doesn't matter when you schedule the addition. You can
> do it at any of the times you suggest. If you change your mind, you
> can *un*-schedule the addition by doing either 'svn revert foo.c' or
> 'svn rm foo.c'.
If foo.c is scheduled for addition (i.e. after 'svn add foo.c') then
'svn revert foo.c' will undo the 'svn add' and leave foo.c as an
unversioned file.
If you try to use 'svn rm foo.c' to undo the add it will fail. You
need to use 'svn rm --force foo.c' which will undo the add and also
delete foo.c from the filesystem.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: how to tell what I need to 'svn add' ?
Posted by Ben Collins-Sussman <su...@collab.net>.
Alexis Huxley <ah...@gmx.net> writes:
> In the SVN user manual it says that sources are registered with the
> working copy by using 'svn add'. Fine, but do people (i) immediately
> 'svn add' stuff as they create it - even though 30 seconds later
> they might realise the file they created was a bad idea, or (ii) 'svn
> add' stuff once the stuff has been around long enough for the person to
> be sure creating the file was more than just a passing fancy or (iii)
> just before 'svn commit' or (iv) at some other 'mental event'? :-)
'svn add' simply schedules a file for addition to the repository;
it's not actually sent until you 'svn commit'.
Therefore, it doesn't matter when you schedule the addition. You can
do it at any of the times you suggest. If you change your mind, you
can *un*-schedule the addition by doing either 'svn revert foo.c' or
'svn rm foo.c'.
As Nathan said, 'svn status' will show you local modifications, and
print '?' next to unversioned things in your working copy -- thus
serving as a reminder that things might need to be added.
> 'svn diff' appears to show the difference between the pristene tree
> and the current tree *excluding* what has not yet been 'svn add'ed
> (I tried touching a new file and then 'svn diff' and no differences
> were shown).
That's true. 'svn diff' shows local modifications to your working
copy. A scheduled addition is a type of local modification. That's
why it's probably easier to just 'svn add' files right when you create
them -- you'll see them in the diffs. You can always un-schedule the
addition later if you want.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
how to tell what I need to 'svn add' ?
Posted by Alexis Huxley <ah...@gmx.net>.
Hi, having successfully compiled SVN a couple of weeks ago, and now
modified all the source trees that I wish to commit to not use symlinks
;-) I now come to actually doing my first 'import'. It worked fine.
I'm not a CVS user (only RCS/SCCS with home-rolled 'releaser' scripts),
so sorry if the following questions are not SVN one, but more on the
philosophy of working with SCM tools.
In the SVN user manual it says that sources are registered with the
working copy by using 'svn add'. Fine, but do people (i) immediately
'svn add' stuff as they create it - even though 30 seconds later
they might realise the file they created was a bad idea, or (ii) 'svn
add' stuff once the stuff has been around long enough for the person to
be sure creating the file was more than just a passing fancy or (iii)
just before 'svn commit' or (iv) at some other 'mental event'? :-)
For myself, I tend to brainstorm a bit and then clean up afterwards,
making me a '(iii)' sort of person, but then I need the equivalent
of 'diff -r <pristene-tree> <current-tree>', but I can't find any
mention of this in the svn man page, or the user-manual or notes
directories. 'svn diff' appears to show the difference between the
pristene tree and the current tree *excluding* what has not yet been
'svn add'ed (I tried touching a new file and then 'svn diff' and no
differences were shown).
Does such a oh-yes-thanks-for-reminding-me-that-i-created-that-file-
but-haven't-svn-added-it-yet tool exist, or do I have to change
the way I work? Can anyone offer technical or philosophical advice,
or point me in the direction of something explaining these things?
Thanks!
Alexis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Peter Davis <pe...@pdavis.cx>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 01 May 2002 14:40, Eric Gillespie wrote:
> svn ln http://foo/repo/trunk/doctools/ .
Another comment from the lowly user: I like this a lot. The one thing I liked
about Visual Source Safe is that it let us link directories into other parts
of the tree, and changes would appear in both places. Copying is totally
great (something that VSS didn't do directly), but linking is useful too.
Even if a text-based modules file is still supported, links should be too.
Or is this handled by symlinks? What happens to symlinks in Windows with the
current version, or do they work at all? Is it possible to create symlinks
with svn from a client running Windows? If not, then 'svn link' should
supplement that.
- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE80GUJNSZCJx7tYycRAvu3AKC4HcABJ759OIckIyehU2nV3PQxtwCfYsBu
ZdH3CsYXIoF2JY5xQlKUaFg=
=3dTU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Ronald V. Simmons" <Va...@thesimmonses.net> writes:
> directory structure in a globally efficient manner... But the problem
> remains that anyone who can commit in one directory can commit in all
> and I have yet to find a combination of LOCATION tags which will let me
> limit write access to subdirectories in the repository.
CVS uses a hack for ACLs. Why can't you use the same hack with
svn? That is, check the username and directory in the pre-commit
hook and bomb if the user isn't allowed to commit in that directory.
--
Eric Gillespie <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by "Ronald V. Simmons" <Va...@thesimmonses.net>.
Ok time to quit being a lurker..
> Unfortunately, symlinks in the repo aren't enough. I believe that Subversion
> will be more multiple-repository-prone than CVS. As an example:
>
> The ASF has one CVS repository, which contains modules for each project:
> httpd-2.0, apr, and apr-util to name a few. However, in SVN land, I believe
> we're have a separate SVN repository for each project. I think the projects
> will want their own directory organization (trunk, branches, tags, whatever)
> and their own (partitioned) set of log messages / revision changes.
>
> As a result, cross-repository "modules" are quite important for SVN. It also
> means that when the ASF switches over to SVN, we can set up a "module" for
> Subversion that references the ASF SVN repositories.
This actually raises a question I've been trying to figure out the answer to for a while now:
I need to control access to the repository at a finer grain than the documentation would indicate is possible. In the example gstein mentions, it's as if I need one set of committers for for httpd-2.0 and another for apr and another for apr-util, with all the sets disjoint. Since SVN is currently lacking the module linking capabilities outlined above, I've placed all my modules in one repository and arranged my directory structure in a globally efficient manner... But the problem remains that anyone who can commit in one directory can commit in all and I have yet to find a combination of LOCATION tags which will let me limit write access to subdirectories in the repository.
(I'm authenticating against OpenLDAP if that matters).
any ideas greatly appreciated.
rvs
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hey:
>
> As for the SQL backend, it would be good if the same instance of the DB could
> be used for all repos on the server, either on or many, if it can be setup to
> do so.
By instance I assume you mean it in the executable sense. My first thought is to
make each repos a schema/user in Oracle. In MySql I think they will have to be
separate DBs but multiple DBs can be served by one mysqld. Other DBs I'm sure can
accommodate this as well.
It should allow for 1 to n instances. Whats important is that the table names
don't collide and that repos getting beaten to death can be easily moved to another
instance if needed. I really want to hide the instance detail behind some sort of
connection URL like is used by JDDC and DBI. "svnadmin create" a little tricky as
it will require more input than a simple URL. I'm betting there is some sort of
XML standard for DDL but I haven't checked yet. But it's too soon to worry about
those details. Right now I'm focused on how to Slide SQL into the mix without
impacting the current development too much.
I don't want to have my work punted to post 1.0 if I can avoid it.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Mark <cm...@yahoo.com>.
--- Eric Gillespie <ep...@pretzelnet.org> wrote:
> I have seen this stated a few other places, but i don't understand
> it. I am currently managing multiple projects in one repository,
> the same way i did in CVS. It works quite well, and i'm sure there
> are advantages i haven't thought of to having them share the same
> database back-end (i imagine this will become even more valuable
> when a SQL back-end becomes available).
>
> I don't want to deal with separate repositories, and i probably
> won't be the only one. What makes you think this behavior opposite
> to that of CVS users will become common?
I am not up to speed on subversion triggers or access contol mechanisms yet,
but I am current managing about 25+ (growing to 50-60 by year end) CVS non-root
pserver repositories on one server. I do this to easily control access to
individual projects, control branch access on individual projects, prevent user
manipulation of CM tags and prevent user UNIX level access to the physical
repository on the server. I can setup the same triggers scripts for all
repositories that read repository specific info/config files to use on policy
enforcement for that project.
I have not had a chance to look into subversion's ablilty to be used as a CM
tool (as opposed to just a version tool used by the open source community) and
its ability to provide triggerable actions for scripts to do CM stuff, but I
would hope it at least allows the CM process level I have on CVS. I am not sure
how atomic commits and related log info from one project will fair as part of
every other projects repository and history. I am looking at the atomic commits
as a comparible feature to ClearCases UCM. A commit being a change set. Not
perfect, but if you try UCM and know its implemetation of change sets,
subversion might not be that far off from perfect when it comes to change sets.
I am sure I am not making much sense (its late, if I'm losing you please read
on I think I have a good point or two below), but when I take over projects
that have had a developer managed CVS repository, I usually break out projects
into their own CVS repos under CM.
It might be that the developer managed repos tend to collect all projects and
the CM managed repos separate them, I guess its how you plan to use the tool
and which method best meets your needs or is the path of least resistance.
However, I see projects come and go. It would be good to be able to cut the
project that is inactive/obsoleted/replaced/canceled or whatever onto CD and
remove it from the server. Or if the project gets transfered to another group
in the company, to be able to transfer the repository would be essential. So
there are reasons for having separate repos for separate projects.
As for the SQL backend, it would be good if the same instance of the DB could
be used for all repos on the server, either on or many, if it can be setup to
do so.
> I don't think cross-repository modules will be as important as you
> think, but if i am wrong there is still a better way to handle it
> than text files.
It might be nice to have a tools repository that is setup to be checked out
with individual project repositories (different projects may be at different
versions of tools, so would have to be linked by tag). Currently this lacking
feature causes projects to store needed tools inside their individual repos.
Mark
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Greg Stein <gs...@lyra.org> writes:
> httpd-2.0, apr, and apr-util to name a few. However, in SVN land, I believe
> we're have a separate SVN repository for each project. I think the projects
I have seen this stated a few other places, but i don't understand
it. I am currently managing multiple projects in one repository,
the same way i did in CVS. It works quite well, and i'm sure there
are advantages i haven't thought of to having them share the same
database back-end (i imagine this will become even more valuable
when a SQL back-end becomes available).
I don't want to deal with separate repositories, and i probably
won't be the only one. What makes you think this behavior opposite
to that of CVS users will become common?
> As a result, cross-repository "modules" are quite important for SVN. It also
> means that when the ASF switches over to SVN, we can set up a "module" for
> Subversion that references the ASF SVN repositories.
I don't think cross-repository modules will be as important as you
think, but if i am wrong there is still a better way to handle it
than text files. If we think of the link behavior i previously
proposed as a hard link, we can think of a symbolic link as a sort
of link the client *does* have to concern itself with.
That is, a link appears identical to a file or directory and the
client goes about its business. Just as hard links are confined
to a single physical filesystem in Unix, this link is confined to
a single repository. A symbolic link, on the other hand, can point
to an external resource. So the client sees that you are committing
to two files, one here in this directory for repository A, and
another here in this symlink for repository B. It sends the changes
to the appropriate repository/server.
Unless there is something i'm missing and there's a good reason
why different projects should not share the same repository, i
won't have much interest in the symbolic link functionality, so i
would provide the original functionality i proposed first. Then,
time permitting, i might work on this second type of link.
--
Eric Gillespie <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> Eric Gillespie <ep...@pretzelnet.org> writes:
>
> > You have the following nodes:
> >
> > /trunk/tools/doctools/ # directory
> > /trunk/foo/ # directory
> > /trunk/foo/foo.c # file
> >
> > svn ln http://foo/repo/trunk/tools/doctools/ trunk/foo/
>
> svn ln http://foo/repo/trunk/tools/foo/ trunk/doctools/
>
> (at least that what my Unix brain wants :)
Oops, no it doesn't. You were right. Sorry.
--
Philip, who knows it's time for bed
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Philip Martin <ph...@codematters.co.uk>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> You have the following nodes:
>
> /trunk/tools/doctools/ # directory
> /trunk/foo/ # directory
> /trunk/foo/foo.c # file
>
> svn ln http://foo/repo/trunk/tools/doctools/ trunk/foo/
svn ln http://foo/repo/trunk/tools/foo/ trunk/doctools/
(at least that what my Unix brain wants :)
>
> Now you have:
>
>
> /trunk/tools/doctools/ # directory
> /trunk/foo/ # directory
> /trunk/foo/doctools # link to /trunk/tools/doctools/
> /trunk/foo/foo.c # file
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Bill Tutt" <ra...@lyra.org> writes:
> So, if you want links, I'd highly recommend doing the symbolic link
> approach first. They fit much more nicely into SVN's data model, don't
> have issues when people create a branch (since they can be
> path-relative), and are certainly much easier to implement.
I think you misunderstand, or perhaps VSS's implementation was
poorly thought out. Let's look at it in the Unix filesystem first.
You have three files, foo, bar, and baz. foo is a regular file,
bar is a link, and baz is a symbolic link. You 'cp foo bar baz
quux' where quux is a directory. Then you echo a bit of text to
the end of each file in quux. With foo and bar (the regular file
and hard link, respectively), the originals have not been modified.
With baz, the original has been modified (assuming it pointed at
an absolute path, of course).
That's exactly how i see svn's links working (at least hard links,
as i've said, i'm not terribly interested in soft links). Now
let's see how this works in svn:
You have the following nodes:
/trunk/tools/doctools/ # directory
/trunk/foo/ # directory
/trunk/foo/foo.c # file
svn ln http://foo/repo/trunk/tools/doctools/ trunk/foo/
Now you have:
/trunk/tools/doctools/ # directory
/trunk/foo/ # directory
/trunk/foo/doctools # link to /trunk/tools/doctools/
/trunk/foo/foo.c # file
Now you have a link (called doctools) in foo. After a few months
of work, you 'svn cp trunk/foo/ branches/foo/foo-2.0'. Now you have:
/trunk/tools/doctools/ # directory
/trunk/foo/ # directory
/trunk/foo/doctools/ # link to /trunk/tools/doctools/
/trunk/foo/foo.c # file
/branches/foo/foo-2.0/doctools/ # *copy* of /trunk/tools/doctools/
/branches/foo/foo-2.0/foo.c # *copy* of /trunk/foo/foo.c
Committing in doctools on the branch affects no other copies. Note
that no one dereferenced the link, just as in the Unix filesystem.
That's just the nature of hard links; they exist in directory nodes,
not file nodes.
--
Eric Gillespie <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: svn modules (was Re: Features and release dates)
Posted by Bill Tutt <ra...@lyra.org>.
I'm not particularlily happy about VSS's sharing concept. The concept
tends to break down when you want to create a branch in VSS. VSS's
sharing concept maps to a hard link concept in SVN's filesystem. Due to
SVN's filesystem schema, and it's O(1) copy behavior creating a branch
that contains a hardlink will not always produce a result that makes
sense. Especially if the hard link isn't tied to just one point in time.
(The new NodeID PK mechinism, and how it interacts with NodeID concepts
makes hard links spanning repository revisiions more difficult.)
So, if you want links, I'd highly recommend doing the symbolic link
approach first. They fit much more nicely into SVN's data model, don't
have issues when people create a branch (since they can be
path-relative), and are certainly much easier to implement.
Bill
> From: Greg Stein [mailto:gstein@lyra.org]
>
> On Wed, May 01, 2002 at 04:40:16PM -0500, Eric Gillespie wrote:
> >...
> > I don't like the text-file based modules. CVS does that and it
> > drives me nuts. Subversion doesn't really need to duplicate this
> > feature. All that is necessary is a kind of symlink in the repo.
>
> Unfortunately, symlinks in the repo aren't enough. I believe that
> Subversion
> will be more multiple-repository-prone than CVS. As an example:
>
> The ASF has one CVS repository, which contains modules for each
project:
> httpd-2.0, apr, and apr-util to name a few. However, in SVN land, I
> believe
> we're have a separate SVN repository for each project. I think the
> projects
> will want their own directory organization (trunk, branches, tags,
> whatever)
> and their own (partitioned) set of log messages / revision changes.
>
> As a result, cross-repository "modules" are quite important for SVN.
It
> also
> means that when the ASF switches over to SVN, we can set up a "module"
for
> Subversion that references the ASF SVN repositories.
>
> The strategy for modules, as outlined in the issue, easily supports
> cross-repository modules.
>
> >...
> > This is more general-purpose and much more flexible than modules.
> > What does everyone think?
>
> Hard and soft links in the repository will be extremely handy. As long
as
> your patches for implementing them come in digestible chunks, then I
don't
> see any obvious reason that we would /not/ include them before 1.0.
Even
> if
> you don't get them all done by 1.0, we could still include partial,
> incremental support for links.
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Greg Stein <gs...@lyra.org>.
On Wed, May 01, 2002 at 04:40:16PM -0500, Eric Gillespie wrote:
>...
> I don't like the text-file based modules. CVS does that and it
> drives me nuts. Subversion doesn't really need to duplicate this
> feature. All that is necessary is a kind of symlink in the repo.
Unfortunately, symlinks in the repo aren't enough. I believe that Subversion
will be more multiple-repository-prone than CVS. As an example:
The ASF has one CVS repository, which contains modules for each project:
httpd-2.0, apr, and apr-util to name a few. However, in SVN land, I believe
we're have a separate SVN repository for each project. I think the projects
will want their own directory organization (trunk, branches, tags, whatever)
and their own (partitioned) set of log messages / revision changes.
As a result, cross-repository "modules" are quite important for SVN. It also
means that when the ASF switches over to SVN, we can set up a "module" for
Subversion that references the ASF SVN repositories.
The strategy for modules, as outlined in the issue, easily supports
cross-repository modules.
>...
> This is more general-purpose and much more flexible than modules.
> What does everyone think?
Hard and soft links in the repository will be extremely handy. As long as
your patches for implementing them come in digestible chunks, then I don't
see any obvious reason that we would /not/ include them before 1.0. Even if
you don't get them all done by 1.0, we could still include partial,
incremental support for links.
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
Re: svn modules (was Re: Features and release dates)
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> > If I do not want to use doctools main trunk version, but a bug fixed and
> > stable version (tagged with DOCTOOLS_STABLE), how should I create the link
> > then?
>
> Well, in Subversion a "tag" is simply a cheap copy, so
>
> svn ln http://foo/repo/tags/DOCTOOLS_STABLE/ .
Oops, that should be
svn ln http://foo/repo/tags/DOCTOOLS_STABLE/ doctools
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Philip Martin <ph...@codematters.co.uk>.
Zack Weinberg <za...@codesourcery.com> writes:
> So suppose I lay out the merged repository like so:
>
> repo/complete/gcc
> gdb
> binutils
> libiberty
> ...
> gcc/trunk/gcc == ../../../complete/gcc
> libiberty == ../../../complete/libiberty
> gdb/trunk/gdb == ../../../complete/gdb
> libiberty == ../../../complete/libiberty
>
> Then I want to be able to 'svn cp' gcc/trunk to gcc/3.1-branch, check
> in patches to gcc/3.1/gcc/whatever.c, and have whatever.c record a
> proper branch in its per-file history.
>
> I also want to be able to check out repo/gcc/3.1.0-release,
> repo/gdb/5.1.1-release, repo/binutils/2.12.4-release, all into the
> same directory, have something sensible happen with files that are
> shared between the threee, and then do "svn up" later and have each
> subset of files track the branch it was checked out from. You try
> this with CVS and directories that are shared between the branches
> tend to get confused which branch you want them on.
Well, Subversion doesn't support checking-out multiple URLs into the
same directory. So you can't do
svn co .../repo/gcc/3.1.0-release -d wc/
svn co .../repo/gdb/5.1.1-release -d wc/
I don't know if there are any plans to change this. The admin file
wc/.svn/entries stores the URL used to checkout the directory, and at
present Subversion pretty much assumes that the directory has a single
URL.
You may be able to use the switch command to get what you want,
something like
svn co .../repo/complete -d wc/
cd wc/gcc
svn switch .../repo/3.1.0-release
cd ../gdb
svn switch .../repo/5.1.1-release
perhaps?
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Zack Weinberg <za...@codesourcery.com>.
On Wed, May 01, 2002 at 11:26:37PM +0100, Philip Martin wrote:
> > > This is more general-purpose and much more flexible than modules.
> > > What does everyone think?
> >
> > If I do not want to use doctools main trunk version, but a bug fixed and
> > stable version (tagged with DOCTOOLS_STABLE), how should I create the link
> > then?
>
> Well, in Subversion a "tag" is simply a cheap copy, so
>
> svn ln http://foo/repo/tags/DOCTOOLS_STABLE/ .
Let me ask a related question. This is going to require a fair bit of
context, please bear with me.
The GNU toolchain projects (GCC, GDB, binutils) are seriously
considering moving to Subversion once it has enough functionality and
stability. Currently GCC has one CVS repository, and GDB+binutils+a
bunch of other stuff share another. However, notionally it's all one
big source tree, and there are a lot of files which are shared between
the two repositories.
It would be sensible to merge the two when we switch to Subversion -
the basic reason it hasn't been done already is that it's considered
too risky. However, we want to do this in a way that lets people keep
working the way they have been. One key issue with that is the
ability to tag just a subgraph of the file tree. We want people who
check out the GCC 3.1 release label to get nothing but GCC 3.1; if
they got anything more, they might incorrectly think that the rest of
the software had been through a proper QA cycle when it hadn't.
So suppose I lay out the merged repository like so:
repo/complete/gcc
gdb
binutils
libiberty
...
gcc/trunk/gcc == ../../../complete/gcc
libiberty == ../../../complete/libiberty
gdb/trunk/gdb == ../../../complete/gdb
libiberty == ../../../complete/libiberty
Then I want to be able to 'svn cp' gcc/trunk to gcc/3.1-branch, check
in patches to gcc/3.1/gcc/whatever.c, and have whatever.c record a
proper branch in its per-file history.
I also want to be able to check out repo/gcc/3.1.0-release,
repo/gdb/5.1.1-release, repo/binutils/2.12.4-release, all into the
same directory, have something sensible happen with files that are
shared between the threee, and then do "svn up" later and have each
subset of files track the branch it was checked out from. You try
this with CVS and directories that are shared between the branches
tend to get confused which branch you want them on.
zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Philip Martin <ph...@codematters.co.uk>.
Nicklas Larsson <ki...@lysator.liu.se> writes:
> > Let's look at how this would work:
> >
> > svn co http://foo/repo/trunk/foo/
> > cd foo
> > svn ln http://foo/repo/trunk/doctools/ .
> > svn ci
> > svn up # at this point the doctools directory becomes populated
[snip]
> > This is more general-purpose and much more flexible than modules.
> > What does everyone think?
>
> If I do not want to use doctools main trunk version, but a bug fixed and
> stable version (tagged with DOCTOOLS_STABLE), how should I create the link
> then?
Well, in Subversion a "tag" is simply a cheap copy, so
svn ln http://foo/repo/tags/DOCTOOLS_STABLE/ .
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Nuutti Kotivuori <na...@iki.fi>.
Nicklas Larsson wrote:
>> This is more general-purpose and much more flexible than modules.
>> What does everyone think?
>
> If I do not want to use doctools main trunk version, but a bug fixed
> and stable version (tagged with DOCTOOLS_STABLE), how should I
> create the link then?
I believe there are no tags in subversion. A tag is a copy of the tree
under another path.
So, just linking looks very nice to me, if it's implementable - I was
personally thinking just a similar kind of thing.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn modules (was Re: Features and release dates)
Posted by Nicklas Larsson <ki...@lysator.liu.se>.
On Wed, 1 May 2002, Eric Gillespie wrote:
> Karl Fogel <kf...@newton.ch.collab.net> writes:
>
> > Actually, modules just got a whole lot closer. See recent changes to
> >
> > http://subversion.tigris.org/issues/show_bug.cgi?id=517
> >
> > Anyone feel like taking it on?
>
> A co-worker and i have been kicking around the idea of writing code
> for symlinks in the repository for internal use (we're anxious to
> dump CVS :). We would of course contribute the patch, but i figured
> you wouldn't take it until after 1.0. Since it sounds like you
> might, let me describe the approach we were planning and see what
> you think.
>
> I don't like the text-file based modules. CVS does that and it
> drives me nuts. Subversion doesn't really need to duplicate this
> feature. All that is necessary is a kind of symlink in the repo.
> Clients don't even know that something is a link; they see only a
> file or directory (whatever the link points to). We'll probably
> want some way for the client to discover if a node is a link or
> not (the user might want to know for example), but under normal
> operation the client neither knows nor cares.
>
> Let's look at how this would work:
>
> svn co http://foo/repo/trunk/foo/
> cd foo
> svn ln http://foo/repo/trunk/doctools/ .
> svn ci
> svn up # at this point the doctools directory becomes populated
>
> # How many copies of the GPL do you have in your CVS repo? :)
> svn ln http://foo/repo/trunk/licenses/BSD COPYING
>
> When committing to a link, the client behaves as it always has.
> But the ra layer knows this is a link and performs the action on
> the link target.
>
> This is more general-purpose and much more flexible than modules.
> What does everyone think?
If I do not want to use doctools main trunk version, but a bug fixed and
stable version (tagged with DOCTOOLS_STABLE), how should I create the link
then?
// Nicklas Larsson
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
svn modules (was Re: Features and release dates)
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Actually, modules just got a whole lot closer. See recent changes to
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=517
>
> Anyone feel like taking it on?
A co-worker and i have been kicking around the idea of writing code
for symlinks in the repository for internal use (we're anxious to
dump CVS :). We would of course contribute the patch, but i figured
you wouldn't take it until after 1.0. Since it sounds like you
might, let me describe the approach we were planning and see what
you think.
I don't like the text-file based modules. CVS does that and it
drives me nuts. Subversion doesn't really need to duplicate this
feature. All that is necessary is a kind of symlink in the repo.
Clients don't even know that something is a link; they see only a
file or directory (whatever the link points to). We'll probably
want some way for the client to discover if a node is a link or
not (the user might want to know for example), but under normal
operation the client neither knows nor cares.
Let's look at how this would work:
svn co http://foo/repo/trunk/foo/
cd foo
svn ln http://foo/repo/trunk/doctools/ .
svn ci
svn up # at this point the doctools directory becomes populated
# How many copies of the GPL do you have in your CVS repo? :)
svn ln http://foo/repo/trunk/licenses/BSD COPYING
When committing to a link, the client behaves as it always has.
But the ra layer knows this is a link and performs the action on
the link target.
This is more general-purpose and much more flexible than modules.
What does everyone think?
--
Eric Gillespie <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Features and release dates
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> > Now, when I read that 1.0 will probably not include annotate and module
> > support, the most obvious question is, how much longer will it take to
> > finish the version with annotate and module support?
>
> Those two features *could* make it in by 1.0, but at this point it's
> not likely we have time to finish them, unless a new army of
> volunteers comes out of nowhere. My guess is that they'll probably be
> implemented soon afterwards, like in 1.1.
Actually, modules just got a whole lot closer. See recent changes to
http://subversion.tigris.org/issues/show_bug.cgi?id=517
Anyone feel like taking it on?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Features and release dates
Posted by Greg Stein <gs...@lyra.org>.
On Wed, May 01, 2002 at 02:03:57PM -0500, Ben Collins-Sussman wrote:
> Greg Hudson <gh...@MIT.EDU> writes:
>
> > If I'm following the discussion correctly, the dump format will include
> > a complete plaintext for each revision of a node. I imagine that in
> > some case, this will make the dump of a database prohitively large--for
> > instance, a repository which has large CAD drawings which change
> > frequently.
>
> We're only doing this right now for simplicity. Certainly, we could
> create a different version of our dumpfile format (version 2?) that
> stores svndiff data in each changed node.
The dump format is also a single file/stream, which means that you can pipe
it to stdout, feed that into gzip, then take the result and 'split' it or
send it over a socket to another computer, or whatever.
Second, if a dump of the entire repository is too large, then you could dump
out subranges of the revisions.
A variant on the first option, you could also pipe the dump into a filter
which runs svndiff to construct your modified svndiff-based dump format.
[ ah, how glad I am that we defined the format to be a single file/stream
rather than multiple files ]
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
Re: Features and release dates
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> If I'm following the discussion correctly, the dump format will include
> a complete plaintext for each revision of a node. I imagine that in
> some case, this will make the dump of a database prohitively large--for
> instance, a repository which has large CAD drawings which change
> frequently.
We're only doing this right now for simplicity. Certainly, we could
create a different version of our dumpfile format (version 2?) that
stores svndiff data in each changed node.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Features and release dates
Posted by Ben Collins-Sussman <su...@collab.net>.
Nicklas Larsson <ki...@lysator.liu.se> writes:
> Hi,
>
> I just saw that the feature list for version 1.0 has been changed on the
> project page.
Yeah, now that we're getting nearer a 1.0 release this summer, we were
tired of misleading newbies coming to the website. :-)
> Now, when I read that 1.0 will probably not include annotate and module
> support, the most obvious question is, how much longer will it take to
> finish the version with annotate and module support?
Those two features *could* make it in by 1.0, but at this point it's
not likely we have time to finish them, unless a new army of
volunteers comes out of nowhere. My guess is that they'll probably be
implemented soon afterwards, like in 1.1.
> Another thing that I would like to ask is if something important in the
> database will change between 1.0 and x.x when modules are supported?
Certainly, the repository features and internal implementations will
change over time. But that's why we have a repository dump/load file
format -- so you can migrate your data from an older repository to a
newer repository.
> Is it safe for a company to start using SubVersion at version 1.0?
That's the only difference between Alpha and 1.0: safety. :-)
> Will SubVersion 1.0 be able to convert a CVS repository on its release
> date?
Yes. cvs2svn is a work already in progress.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svn and module support
Posted by Nicklas Larsson <ki...@lysator.liu.se>.
The way that we are thinking of using the source control system is like
this:
* We want to split up the code into modules. Each module will exist in a
number of versions.
* We are delivering on a number of platforms.
* We are delivering a number of products on each platform.
* Every product has needs of different sets of modules, and will need
different versions of each module.
* A product should be set up in the system so it can check out all the
modules with the right versions with a single command. When one person
working on this project has set up the modules that should be used in the
product, then all other members of the group can check out the product
module.
I am not a CVS expert (and not a SubVersion expert either :-)), but from
what I understand, the working model above can be used together with CVS,
but you will need to use some special tricks to make it working.
So, will the described working model be:
1: Easier to follow with SubVersion
2: About the same difficulties as with CVS
3: Harder to follow with SubVersion (or almost impossible)
// Nicklas Larsson
On 1 May 2002, Karl Fogel wrote:
> William Uther <wi...@cs.cmu.edu> writes:
> > svn already support "poor man's modules"? It has `svn switch` :)
>
> Today is my day to respond to module stuff :-). See the recent
> changes to
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=517
>
> for module plan.
>
> > Obviously you'd want something better for full support, but what it has is
> > usable. You do have to set up the links to the module manually for each
> > working copy.
>
> The problem with using switch and svn cp for module support is that
> each copy becomes a branch -- the changes on the branch are no longer
> happening on the original line. Badness :-). I don't think useful
> module support can be had this way.
>
> -K
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svn and module support
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
William Uther <wi...@cs.cmu.edu> writes:
> svn already support "poor man's modules"? It has `svn switch` :)
Today is my day to respond to module stuff :-). See the recent
changes to
http://subversion.tigris.org/issues/show_bug.cgi?id=517
for module plan.
> Obviously you'd want something better for full support, but what it has is
> usable. You do have to set up the links to the module manually for each
> working copy.
The problem with using switch and svn cp for module support is that
each copy becomes a branch -- the changes on the branch are no longer
happening on the original line. Badness :-). I don't think useful
module support can be had this way.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Svn and module support
Posted by William Uther <wi...@cs.cmu.edu>.
On 1/5/02 1:24 PM, "Nicklas Larsson" <ki...@lysator.liu.se> wrote:
> Now, when I read that 1.0 will probably not include annotate and module
> support, the most obvious question is, how much longer will it take to
> finish the version with annotate and module support?
svn already support "poor man's modules"? It has `svn switch` :)
Obviously you'd want something better for full support, but what it has is
usable. You do have to set up the links to the module manually for each
working copy.
% mkdir svntest
% cd svntest
% svnadmin create repos
% svn mkdir file:///Users/will/svntest/repos/trunk -m "add trunk dir"
Committed revision 1.
% svn co file:///Users/will/svntest/repos/trunk
Checked out revision 1.
% cd trunk
% svn mkdir myproj
% svn mkdir myotherproj
% svn mkdir mymodule
% cd myproj
% svn mkdir mymodule
% cd ../myotherproj
% svn mkdir mymodule
% cd ..
% svn commit -m "set up stuff"
Adding mymodule
Adding myotherproj
Adding myotherproj/mymodule
Adding myproj
Adding myproj/mymodule
Committed revision 2.
% ls
mymodule myotherproj myproj
% cd myproj
% svn switch mymodule file:///Users/will/svntest/repos/trunk/mymodule
Updated to revision 2.
% cd ../myotherproj
% svn switch mymodule file:///Users/will/svntest/repos/trunk/mymodule
Updated to revision 2.
% cd ../mymodule
% cat > modulefile
this is the modulefile
% svn add modulefile
A modulefile
% svn commit -m "add modulefile"
Adding mymodule/modulefile
Transmitting file data .
Committed revision 3.
% cd ..
% svn up
A ./myproj/mymodule/modulefile
A ./myotherproj/mymodule/modulefile
Updated to revision 3.
% cd myproj/mymodule
% ls
Modulefile
% more modulefile
this is the modulefile
Later,
\x/ill :-}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org