I'll be at CERN tomorrow. I'll reimport images and move stuff.

> I now work at http://www.cliss21.com.

Lot of Linux mentioned as OS, but we wont mention it :)

What branches and tags did you kept?

Tags that are not release tags no longer means anything and are a waste of space (painy while browsing with cvsweb).

> IMHO the SVN page should provide more generic information and let the user

> understand that SVN repositories doesn't have a layout as fixed as CVS
> repositories (something I didn't realize myself when reading it). It would
> make more sense to make the information more generic than modifying an SVN
> repository to fit the old documentation.

The point of such page is not to be a poor substitue to the SVN manual, it is to provide a few useful commands.
People should get a working command to get anonymously a copy of the repository.
The fact that SVN allows flexible layout is okey but for Gna it does not really helps. For a site like Gna, the point is to have a usual layout working correctly for most.

> I'm moving around 1000km North tomorrow so I will be unreachable for a day or

This puts you out of France, doesn't it? :)

Timothee, thanks for the details. I'm now able to reimport the repository.

Can you just answer this question:
Do you think moving directories around can be an issue when performing searches later on? Maybe in ViewCVS, which seems to limit a search to a repository path?

> I dont get why dead branches would be important. All changes
> are stored, what happened specifically on a given branch is
> not really an issue.

Following this, all changes from the trunk are stored in HEAD and we can trash the rest :)

Given the heavy changes that happened in some branches, I do think we should keep the intermediary steps.

> But we would remove anonymous access to the repository so
> nobody download it

This will prevent people from 'cvs diff'ing their repository (which I did when switching Savane at Savannah to SVN).

I'd rather just lock the write access to the repository, remove indeed the CVS link from the interface, and possibly add a top-level IMPORTANT_NOTE (or the like) containing:
---
The Savane development moved the Subversion (SVN). This CVS repository is now outdated. Please check https://gna.org/svn/?group=savane for how to access the new SVN repository.
---

> I want the Savane project SVN page to provide useful
> commands and currently it does not.

IMHO the SVN page should provide more generic information and let the user understand that SVN repositories doesn't have a layout as fixed as CVS repositories (something I didn't realize myself when reading it). It would make more sense to make the information more generic than modifying an SVN repository to fit the old documentation.

Aside from that I've got no problem with the layout you suggest.

More on this later, I need to eat dinner :)

I'm sorry but I do not have the time to work on a conversion again. I have a two weeks old baby at home and it's way harder than anything I had expected :-)

The initial conversion I did took a fair amount of time to do as well. To obtain the modules/{branches,tags,trunk} layout, I converted each module individually, then used svndumpfilter on each to remove the branches we didn't want to keep, then loaded up the modules one after the other into a new repository.

If you want a single {branches,tags,trunk} at toplevel and the modules below, it's easier as you won't need to break down the convert module by module and reconstruct.

You can post here whenever you need a little push on things.

(Timothee, please read this :))

After investigation, cvs2svn did its job correctly: .png's are considered text files by CVS, but since we only work under Unices, that never was an issue. However SVN tries to convert text files to the local platform even under Unix, hence the binary corruption. The fix is to either recommit files as binary, or cvs -kb *.png and reconvert.

Are .png's the only binary files we have in Savane? I quickly checked, but I'm not sure.

After some thoughs, I'm think we should keep all our branches (just like we keep the trunk history); if needed we can move the branches "directories" away or even remove them later, but the history will be kept. Especially since Mathieu want to remove the CVS repository; on that point I would really prefer to make it readonly (chown -R root:root .).

Likewise, I think we should also run --cvs-revnums to be able to know which CVS revision a given SVN revision matches.

Should we keep CVSROOT somewhere in a corner of the SVN repository, in case the CVS repository gets trashed some day?

About the layout, there are 2 issues to consider:
1) if repositories/modules are imported in several steps, date range searches are broken. Since we import truly independent modules, this should not be an issue, but this way makes us restart the cvs2svn conversion.
2) we can 'svn mv' repositories around after the conversion; however we may have trouble searching the history from within a directory that changed over time that way. Timothee, can you enlighten us about this? :)

I also saw yet another layout like:
/
|-savane
|-savane-branches
|-savane-tags
...

It might be good as well, I dunno.

Last, I would like to get the commands that were used to generate the first conversion. Timothee? :)

I think I would use this one to reconvert the repository with subsequent 'svn mv' for reorganizing:
cvs2svn --use-cvs --cvs-revnums --fs-type=fsfs --username=beuc --mime-types=/etc/mime.types -s svn-repo cvs-repo

Or if we import module per module (not tested):
svn init ...
for modname in cvs-repo/*
do cvs2svn --use-cvs --cvs-revnums --fs-type=fsfs --username=beuc --mime-types=/etc/mime.types --dumpfile=$modname.dump cvs-repo/$modname
svnadmin --parent-dir $modname load /path/to/svnrepo < $modname.dump
done

Btw, the Savane CVS instructions mention "<modulename>" in italics; I think the SVN instructions can do the same. SVN is apparently designed to have a quite flexible directory layout, and developers can user 'svn mv' to reorganise it - enforcing a sitewide layout with a default module doesn't sounds good nor effectively doable.

In my opinion, we would be better off by starting the conversion from CVS to SVN again. It feels more right and seems to be a cleaner approach.

About the conversion: I don't know if this is important, but all text files in Savane are in UTF-8 encoding, not ASCII. Mostly, this doesn't make a difference, but some files contain characters higher than the standard ASCII set.

Regarding the repository layout: As I understand it, it should be possible to achieve the wanted goal. Our current layout is as follows (I hope this gets transferred correctly):

/
|
+-devel
| |
| +-branches
| +-tags
| +-trunk
|
+-moved_out
| |
| +-branches
| +-tags
| +-trunk
|
+-savane
|
+-branches
+-tags
+-trunk

If we switch over to this layout:

/
|
+-savane
|
+-branches
+-devel
| |
| +-branches
| +-tags
| +-trunk
+-moved_out
| |
| +-branches
| +-tags
| +-trunk
+-tags
+-trunk

Everything should work as expected then. To check out the Savane trunk, you'll type this command:

$ svn co svn+ssh://name@svn.gna.org/svn/savane/trunk savane

To get the other modules, you'll need this:

$ svn co svn+ssh://name@svn.gna.org/svn/savane/devel/trunk devel
$ svn co svn+ssh://name@svn.gna.org/svn/savane/moved_out/trunk moved_out

Correct me if I'm wrong.

And, by the way: What is "devel" and "moved_out" all about, anyway?

> Since apparently only 2 images are affected, that should be easy.

There are quite a lot of images affected. I only cited 2 examples.

Are you sure the origin is the non-detection of binary RCS files? If yes, we need to either check/reupload all the binary files in Savane (only images?), or restart the SVN migration from scrach (I don't think there were any commit since the migration besides Mathieu's test). Plus you might want to notify Gna! projects that were migrated likewise.

Since apparently only 2 images are affected, that should be easy.

About the modules mess? :)

Maybe there's something to do to get images treated like binaries before the conversion?

I'd like to stress bug #4535 :)
I got some corrupted images when performing a checkout.

Wouldn't it be possible to add a field to e.g. table_groups, so the admin could specify the main module, if the group uses several modules? This could then be added to the default repository location. If the field is not set, the default location will be shown without modifications.

I could imagine that we're not the only project with more than one module, so it would be of benefit to other groups as well.

Hum, I noticed that the commands in https://gna.org/svn/?group=savane are broken, a /savane must be added.

Is there no way to get the provided command to get the main module? I assume it has something to do with the fact there are 3 modules.

If there's no way, maybe we should just trash moved_out and put devel into /savane

the conversion is done. I guess we'll close this soonish if there's no followup?

> I am starting to work on the conversion

That's great news. Does this mean that we are now officially in a deep freeze, i.e. absolutely no commits to the CVS?

We could say that nothing should be committed to the CVS from now on. Could you handle the SVN migration, Timothee?

We would need to migrate everything and keep only the REL_ tags. No branch is accurate for now (all merged), they can all be trashed.

I can do that yeah. So are you saying we should go ahead with the conversion?

There are 3 modules in the savane cvs atm ( devel, moved_out and savane ), I take it only savane/ needs to be converted?

Also if we do a conversion, anything that gets checked in to the CVS after I grab a snapshot of it has to be manually applied to the SVN repository once it's done, or it will be lost.

Doing the move, we should skip DEV_* tags and useless old tags. (just to keep REL_* tags), apart ongoing DEV_* tags.

"I see no reason to go to SVK"

That's IMHO a bad way to consider the issue. And I do see one: when maintaining non-trivial local, specific, often temporary, unmergeable changes, it's way better to go distributed. The other solution, that we currently use, is to hardcode Gna! and Savannah-specific backend bits in the standard release.

Also, "since Savane comes from CVS" - well, the Linux kernel developpers, respectable users of distributed SCMs, used to use CVS :)

I wanted to know if a SVN repository can be properly merged with an external branch, hence maintained by SVK. This depends on whether SVK is considered to work with any SVN repo, or if it's considered as an upgrade path, with no "backward" compatibility (but this wouldn't make it an useless tool anyway).
For example it could require additional commit metadata in both repositories. I'll have a look asap.

Hi,

just a little data on the conversion from cvs to subversion: Using cvs2svn, it took about 1.5 hours on my computer. There were three warnings, but the repository still could be converted alright. The size of the repository is 80M for cvs versus 147M for svn.

I can use svn to work with the newly created repository, and it looks like it works normal. I didn't check it with svk, however.

Regarding other SCMs, I think that Bazaar-NG (http://www.bazaar-ng.org) is quite promising, but it's not yet ready for production use. GNU Arch is not going to be developed much further, and its successor, baz, will be faded out in favour of bazaar-ng.

I can't really say much about git, monotone, darcs and friends.

With regard to changing the SCM again in a year or two, I don't think that this is evil per se. If there are features or possibilities which warrant such a step, I wouldn't mind doing such a conversion again.

Well, only time will tell whether we see the need to change our SCM again.

While I won't recommend any other SCM (they are evolving too much and it's time consuming to keep track of them), I disagree with the general ideas of your arguments.

We've lived without cell phones for decades, but that's not something I'd feel like giving up now, so I don't like that kind of argument.

"supported on most system" just means it runs under Woe32, and I don't think we need that anyway. Savane could even use Arch in this regard, since it works for Unix-like platforms. I feel anyway that the problem is more the rapidly changing nature of the current tools rather than their platform support (monotone runs well under Woe32, and is incidentally used by projects as large as Xaraya).

It's currently as difficult to make a personal branch than it is to contribute back such a branch. A distributed system makes forking as easy as merging.

Merging is btw what I'll need to check wrt SVK. Maybe you easily grab a SVN project with SVK, but maybe that's not as easy to merge without SVK on both sides, dunno.

I would like to get a distributed system, eg a way to grab Savane, work offline, do personal branching stuff and the like. I really needed that when working on merging stuff progressively from "FSF-Savannah" to Savane.

What about SVK? Can it SVK work on top of any SVN installation, or does it need to be SVK from the start?

If not, I'm not opposed to SVN - as it improves on CVS - but I'd like us to keep in mind that a new SCM change would be good in the near future, like in one year or two.

Unless I'm mistaken, cvs2svn is installed on one of Gna machines.

Note that you could try if you want, at https://gna.org/cvs/?group=savane there are link to sourcecode repository daily backup
http://cvs.gna.org/daily/savane.tar.gz

Well, we'll have to prepare such migration, so it's not for tomorrow morning. But I think at some point that a move that will benefits all of us.

I suggest that we move development over SVN.

It now seems quite stable, used by large projects like KDE.

SVN is in the spirit of CVS so we should have a lot to learn.

And it would be helpful to manage branches or to do things that we actually do several times a year like removing directories, moving files.

From what I know from Arch, I'm not uber-interested regarding Savane development.

Any thoughts? Does anyone have experience with SVN already?