svn move

Virion · Post by **Virion** » Thu May 31, 2007 3:00 pm

Re-edited wiki, correct command is
svn co https://irrlicht.svn.sourceforge.net/sv ... icht/trunk irrlicht

Always check out trunk if there's no specific reason to do otherwise.

my svn automatically checked trunk.

hybrid · Post by **hybrid** » Thu May 31, 2007 9:11 pm

Since SVN handles branches and tags the same it does IMHO *not* really make sense to make a difference in the directory structure. You can check the SVN repository on the sourceforge pages if you want to know what is possible.
If the SVN guys would have fixed this in SVN it wouldn't have been such a problem with such many conventions. So be happy with how it is now or complain with the SVN developers!

anylo · Post by **anylo** » Thu May 31, 2007 9:49 pm

hybrid wrote:Since SVN handles branches and tags the same it does IMHO *not* really make sense to make a difference in the directory structure.

You're missing the whole point of branches and tags.

The difference is not in the way how SVN itself technically handles the branches and tags (answer is: "exactly the same way"). The difference is in the concept: you'll make a new branch when you're trying something that cannot be done in trunk (like implementing something totally different which will cause trouble for other developers).

Tags are just snapshots of certain revision, like v1.3 would be a snapshot of revision 556.

Another common version control concept is a tag. A tag is just a “snapshot” of a project in time. In Subversion, this idea already seems to be everywhere. Each repository revision is exactly that—a snapshot of the filesystem after each commit.

However, people often want to give more human-friendly names to tags, like release-1.0. And they want to make snapshots of smaller subdirectories of the filesystem. After all, it's not so easy to remember that release-1.0 of a piece of software is a particular subdirectory of revision 4822.

http://svnbook.red-bean.com/nightly/en/ ... merge.tags

For me it's totally same how you're doing it and there's no right or wrong way to do it. Except that everybody else is doing it differently than you.

hybrid · Post by **hybrid** » Thu May 31, 2007 11:33 pm

In fact the releases will also be updated in case of major bug fixes which can be backported from trunk. So why would we want to keep separate tags then? That would be just a complete copy for nothing. Making tags fixed snapshots is definitely what SVN intends by making a complete copy of the whole repository. So in order to make a tag and maintain that version in parallel to trunk the SVN book suggests to make two copies then? I guess then CVS should have gotten a better binary handling and local caching instead...

sRc · Post by **sRc** » Fri Jun 01, 2007 12:02 am

no you don't make an actual copy of the files, you just makes links to the states at that revision. duplicating the files themselves would be stupid

Subversion does not create an entire new file in the repository with its copy. Instead, the old and new files are linked together internally and the history is preserved for both. The copied files only take up a little extra room in the repository because Subversion only saves the differences from the original files.

the point of tags is creating a seperate area that doesn't have any more commits to it for releases.

hybrid · Post by **hybrid** » Fri Jun 01, 2007 9:44 am

I know the way SVN handles copies internally, but that's not the point here, It's about the way you'd use tags. And the way it seems to be meant is IMHO pretty useless. We'll write up important revision numbers in the Wiki, you can get them with 'svn up -r revnumber'. I think the releases (maintained ones) are the only ones we really care for.

Virion · Post by **Virion** » Fri Jun 01, 2007 10:13 am

Luke wrote:the SkinnedMesh branch is the new animation system thing.

why is it seperated?

hybrid · Post by **hybrid** » Fri Jun 01, 2007 11:06 am

Because it is a branch until it gets merged into the core.