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

replacement to cvs release?

From: Martin Steffen <ms_at_informatik.uni-kiel.de>
Date: 2006-02-28 09:58:31 CET


I'm new to svn (but a long-time CVS user).

My question is: how can I have something similar than cvs release?

I'm aware, that the issue has been discussed before in the archives, and
the answer seems to be: there's no such thing, just svs-delete the
directory (or just \rm, as one suggestion was), relax, and go ahead.

I understand that, but I'm not fully happy.

The reason why is as follows. Just \rm -rf make the subdirectory re-appear
in the next update, which is what I wanted to avoid by ``releasing it''
which for me I used as

        ``currently not there and under work, but, if needed you
          can get the full thing back by cvs update -d''

Then of course you could svn-delete it. If ever needed then go back to that
date (or that tag if I happened to do one and go on).

The main problem here is that I find that too flexible. I'm currently
planning some project (with a number of people with varying degree of
exposure to cvs/svn or similar platform). The project might last a few
years, so careful preparation and conventions in the set-up phase might
pay-off. So my concern here is that for certain parts of the project I
would like to ``impose'' or ``fix'' a certain structure for instance


only that at certain points it time the people are not interested in
working on the whole subtree of deliverables/A1, because for some deadline,
deliverables A2 are relevant (and A2 is not a later version of A1, but just
something else.

Just svn-deleting the thing sounds to me that could lead to some mess, if
not done with discipline. Another option could be that in the trunk there's
the perhaps



and the normal user just works with the


which is a ``subset'' of the whole structure and in ./aside is the ``full
thing'', with the same more or less rigid structure. This wish is, for me,
perfectly realized by cvs release -d, because there, the directories which
are currently not in use remain at the place as they should, only that the
do not appear in the workspace, if not explicitly requested by the user.

One thing one could of course do is not checking out


and get the whole thing, but _picking_ the stuff one is interested, like

      checkout deliverables/A1/B2/C3 ./deliverables/A1/B2/C3
      checkout deliverables/A1/B2/C3 ./deliverables/A1/B2/C4

if one is interested only in C3 and C4 now. That's not very convenient, because
I cannot commit back the whole working space in one blow like

        cd deliverables
        svn commit -m"ok"

but I have to do

       cd deliverables/A1/B2/C3
       svn commit -m"ok"
       cd deliverables/A1/B2/C4
       svn commit -m"ok"

which can get lengthy (at the end of the day, one wants one single command
that hands it all back in to the repos, and not much searching/browsing
around in the file system).

So, basically, I'm after a very simple way to use SVN (at least for the
daily work). I like the additional flexibility, but also I want for the
people (and myself) a simple scheme that works, and works over some period
I'm afraid, so to say, of the flexibility and I'd like to avoid fancy
re-arrangements because - it disturbs the people when working on it,
especially new-comers - and I'm afraid, I will not find stuff after 3 year,
if things are in flux (especially if the user find out how to rearrange the
structure according to their preferences.

and it should be simple, because I fear the complex schemas won't be

Ok, long requirements list :-)

any ideas? Or am I worried needlessly?


[PS: I'm not wanting to have the rigid scheme of CVS back (or a simple file synchronizer),
     I like the flexibility, in case of need, but in the day-to-day work,
     I'd like to not think about flexible rearrangements etc.]


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 28 10:04:56 2006

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

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